Sitter och funderar på en modell för ett transfersystem till ett sportspel. Det är ett spel liknande "DrömElvan" (aftonbladet.se). Varje medlem kan ha ett lag, under spelets gång ska man kunna byta spelare som inte går så bra, blir skadade eller ökat i värde mycket. Nu funderar jag på hur jag bör modellera upp detta för att få en enkel och hanterbar implementation i nästa steg.

Implementationen är asp.net och en mysql-databas men det spelar egentligen inte någon roll.

Grundfrågan för mig är tabellen som innehåller transfers, där har jag två förslag på lösning:

Förslag 1

Datum (date)
LagID (int)
SpelareIN (int)
SpelareUT (int)

I denna tabell kan ju spelareUT vara NULL vilket innebär att spelaren som man tagit in inte blivit bortbytt ännu och alltså implicit anger att han är del av laget för tillfället.

Förslag två är mer av händelse/transaktionstänk:

Datum (date)
LagID (int)
HändelseTyp (int) (1=spelareIn, 2=spelareUt)
SpelareID (int)

Det jag känner är ett viktigt design-mål är att det enkelt med procedurer ska gå att få fram vilka spelare som varit med i laget, mellan vilka datum spelaren var med i laget och hur många poäng spelaren bidrog med under den perioden.

Är det någon som har några intressanta ideer hur jag kan modellera detta vidare så blir jag mycket tacksam !!

Att skapa en design som man från början vet kommer innehålla många NULL-värden är ju något som man generellt vill undvika.

Din händelsetabell ger med de kolumner du visar upp inte mycket info om själva transfereringshändelsen, utan det ser nästan ut som en medlemstabell. Transf-tabellen bör kanske kompletteras med transf-summa.

Du ska väl även ha medlemstabell i systemet, alltså vilka spelare är med i vilket lag (just nu)?

Det är möjligt använda transfereringstabellen som en medlemstabell, dvs du kan härifrån härleda vilka spelare som är med i vilket lag just nu. Men det tycker jag är onödigt krångligt. Du får då onödigt komplicerade SQL-frågor och prestandan blir ju inte bättre av att du hela tiden måste söka i den tabellen efter innevarande datum samt köp/sälj när du ska lista spelare i ett lag.
Systemdesignen blir mer svårbegriplig också om spelare som är med i ett lag, men som aldrig blivit transfererade, skall hittas i transfereringstabellen.

Tack för bra synpunkter.

Syftet med transfertabellen är att hålla reda på hur många poäng spelare fått under den tiden de tillhört ett lag. Alltså för historiken avseende lagtillhörighet. Jag måste kunna räkna ut hur många poäng ett lag skrapat ihop under en säsong och behöver då historik om vilka spelare som tillhörde laget vid varje matchtillfälle. Den är alltså inte till för att se vilka som tillhör laget just nu.

Den aktuella laguppställningen finns antingen i tabellen för varje lag eller i en egen tabell. Det handlar ju många till många om jag ska normalisera helt korrekt. Dock vet jag ju att jag alltid kommer ett fast antal spelare i ett lag (7 stycken i ett handbollslag, förstasexan + målvakt) varför jag tror jag lagrar aktuella spelare som attribut i tabellen "LAG".

LAG
ID
Namn
Spelare1
Spelare2
Spelare3
.. osv..
Spelare7

Några andra tabeller för att förklara strukturen:

MATCH
ID
Datum
HemmaLag
BortaLag

MATCH_SPELARPOÄNG
MatchID
SpelarID
Antal_Poäng

När en omgång är färdigspelad vill jag dra igenom alla lag för att räkna ut poängen som de ingående spelarna har fått.

Att sätta ett fast antal kolumner för spelare i ett lag är inte riktigt bra i framtidssyfte. Vad händer om du vill lägga till avbytar/reserver i laget?

Om du inte bryr dig om avbytare till at börja med så skulle jag göra detta:

I MATCH_SPELARPOÄNG lägger du till LagId som kolumn för att visa vilket lag som spelaren tillhörde under matchen. Vilket gör att du kan hålla reda på hur många poäng spelaren har haft när den tillhört ett lag.

Sen skapar du en ny tabell som kopplar ihop lag och spelare som visar vilka som NU tillhör laget. Detta gör att det i framtiden blir enklare att infoga mer information om kopplingen mellan en spelare och ett lag.

Hoppas detta var till nån hjälp. :)

Tja

Tobias >>

Det var ett bra förslag men saken är ju den att varje spelare kan ju finnas i flera lag. Matchen som spelas är en "riktig" match IRL. varje spelare tillhör ju en "ELITKLUBB" som möter en annan "ELITKLUBB". Beroende på hur spelare sköter sig får han poäng. Det är alltså inte en match mellan två LAG. Kanske förvirrande men om du kollar på Drömelvan på www.aftonbladet.se förstår du hur jag menar.

Varje LAG i min tävling består av spelare från olika ELITKLUBBAR. När två ELITKLUBBar möts genererar detta poäng för varje spelare och därmed till varje LAG som SPELAREN tillhör.

Jag funderar på att ha fasta transferperioder, exempelvis 10 st per säsong. Det innebär att jag vet vilka spelare som tillhörde laget vi varje matchtillfälle genom att titta i tabellen LAG (spelare1-spelare7). Transfertabellen blir då endast för att beskriva vilka transfers som varje lag har gjort. Då kan jag också när jag presenterar ett lags transfers, visa hur många poäng en spelare fick ihop under sin tid i LAGET.

Versalerna endast för att förtydliga min modells olika ingående element, inte att uppfatta som skrik ;)

Jag tycker mig fasta för följande variant på TRANSFER-tabell:

TRANSFER
Datum
Lag
Händelse_typ (IN eller UT)
Spelare

När ett nytt lag skapas första gången blir det alltså sju spelare som läggs in som händelse IN med ett datum på händelse. efterhand som SPELARE byts ut kommer händelseloggen visa historiken för varje LAG. Är jag rätt ute ?

Ok, jag tror jag förstår hur du menar. :) Dock finns det i min modell stöd för att både se transfers, ha samma spelare i flera lag och se statistik för kombinationen spelare lag. I tabellen för MATCH_SPELARPOÄNG så är nyckeln sammansatt av LAGID, MATCHID OCH SPELARID. Vilket gör att det går utmärkt att ha flera samma spelare i olika lag i samma match. Samma sak gäller knytningen Spelare och Lag i en separat tabell där nyckeln är sammansatt av LagID och SpelarID. Vilket gör att samma spelare kan befinna sig i flera lag samtidigt.

För att se hur mycket poäng en spelare har gjort för ett lag är det bara att söka i kopplingstabellen för spelare och match på LAGID och SPELARID så har du summan på nolltid. ;)

Lycka till! :)

Bra ide, så hade jag inte tänkt göra men det verkar smart !

Var tänker du att jag ser de transfers som ägt rum historiskt?

Det är ju inte säkert att varje transfer ägt rum till en match utan ett LAG kan teoretiskt sätt ha bytt SPELARE flera gånger mellan två matcher. Jag vill gärna frikoppla transferna från matcherna. Att jag kan se vilka spelare som varit med i laget vid varje matchtillfälle är självklart viktigt. Bör jag då inte ha transferna i en egen tabell ändå?

Du menar att du vill göra en historik för all val en deltagare gjort för sitt lag oberoende om sedan den spelaren var kvar till match? Typ:

Lag A byter ut Spelare1 mot spelare2 men ångrar sig sedan och byter spelare2 mot spelare26. Spelare26 används sedan i en match. Du vill ändå ha koll på att laget gjorde dessa byten trots att spelaren/spelarna aldrig egentligen användes. Det låter som en "Log"-tabell isåfall. Under förutsättning att man enbart gör byten skulle den se ut som följer, enligt mitt förslag:

TRANSFERS
TransferID
LagID
UtbyttSpelarID
InbyttSpelarID
Datum

Då får du även en bonus att det går att se exakt vilken spelare som ersatte en annan. ;)

Ja precis så var det jag menade !

Inte alltid lätt att göra sig förstådd via diskussionsforum, tack för många bra synpunkter. Markerar nu tråden som löst !!

// JS