Respons på datamodell

[remi sture]

Heisann!

 

Har sittet i mange timer her nå og forsøkt å komme fram til en fornuftig datamodell for et kommende prosjekt jeg har på gang, og trenger nå innspill fra dere på hva jeg kan endre på i førsteutkastet. Noe som mangler, bør endres eller droppes?

 

Dette er, som dere kanskje skjønner, altså at system for en fotballside, hvor jeg skal registrere lag, spillere, trenere, kamper, tabeller, og styremedlemmer, for å nevne noe.

 

Cluet er at jeg vil at spillere og trenere og slikt skal kunne legges til i flere sesonger (f.eks 2003,2003,2004) og flere lag (en spiller kan spille på juniorlaget og A-laget, f.eks), slik at jeg kan registrere statistikker over flere år. Er dette mulig slik det er satt opp nå?

 

Bør jeg flytte address, phone, cell og slikt over i en egen tabell, eller er det ikke vits i når det ikke er snakk om mer enn noen hundre personer som skal registreres?

 

I relasjons-editoren i DBDesigner 4 kan man velge hva som skal skje ved sletting og oppdatering (on delete, on update), hvor "No action" er huket av som standard. Andre mulige verdier er: "Restrict", "Cascade", "Set null" og "Set default". Hva betyr de forskjellige, og hva anbefaler dere?

 

Må man forresten bruke InnoDB som tabelltype når man bruker fremmednøkler?

 

http://remisture.no/diverse/datamodell.xml -> arbeidsfil fra programmet DBDesigner 4

 

Endret 25. januar 2006 av remi sture

[remi sture]

Hallaisen!

 

Jeg har nå opprettet en "contantInfo"-tabell (navn, adresse, telefon, osv) og en "post"-tabell. I tillegg har jeg lagt til "links" og "linksCategory", som skal være en linksamling, men har vel egentlig ikke noe med resten av systemet å gjøre.

 

Er dette en bedre løsning, eller gjør det ting mer tungvindt når dette skal hentes ut fra tabellene igjen?

 

(Image-exporteren bugger litt)

Endret 25. januar 2006 av remi sture

[trn100]

Heisann,

 

For det første, jeg har altså bortimot 0 peiling på fotball (mulig det er å banne i hvert fall i ei "kjerke" :-)) og er heller ingen ekspert på databaser, men en ting som slår meg er at du har hele 3 tabeller med personinfo? Hvorfor ikke slå sammen både trenere, styremedlemmer og spillere i samme tabell? Ikke vet jeg, men teoretisk kan vel både dommere eller i alle fall spillere sitte i et styre, og/eller status kan forandre seg? Ved hjelp av en liten kode i en persontabell kan du legge inn aktuell status for hver hver person, f.eks. om vedkommende er spiller, styremedlem og/eller dommer?

 

Når kampdata registreres "bankes" hver enkeltpersons status fast i match tabellen, slik at uavhengig om personens rolle endres underveis vil alltid hver enkelt kampoversikt vise hvilken rolle personen hadde på det aktuelle tidspunktet?

 

Tror kanskje det også hadde forenklet modellen en del :-)

 

Lykke til!

Endret 25. januar 2006 av trn100

[remi sture]

Heisann!

 

tusen takk for tilbakemelding, men jeg må få fikset følgende feilmelding først:

 

"There are circular relations"!

 

Men jeg får ikke beskjed om HVOR dette er. Jeg har sett meg blind på dette nå.

 

http://remisture.no/diverse/datamodell.png

http://remisture.no/diverse/datamodell.xml - Åpnes i DBDesigner 4

[trn100]

Hmmm.... Er i grunnen ikke så forundret over det! Er et problem som ofte dukker opp hos meg også når strukturen blir for komplisert.

 

En metode jeg ofte bruker samtidig med at jeg bygger tabellene er at jeg tester ut ulike spørringer og rapporter underveis for å sjekke om strukturen ikke bare ser bra ut men faktisk også fungerer.

 

Problemet ligger i relasjonene du har definert. En til mange, mange til en, mange til mange og en til en...

 

Er her logikken i første omgang kommer inn.... Deretter testing :-)

[remi sture]

Jeg har vel ikke mange til mange noen steder?

[roac]

Første tanke (det er for sent til at jeg orker å grave meg ned i datamodellen): Postnummer (zip) bør for det første ikke være en integer, for det andre bør den ikke være begrenset til 4 tegn. Dette begrenser blant annet muligheten til å ha utenlandske adresser, og det gir ekstra arbeid den dagen Posten bestemmer seg for endelig å bruke femsifrede postnummer.

[roac]

I relasjons-editoren i DBDesigner 4 kan man velge hva som skal skje ved sletting og oppdatering (on delete, on update), hvor "No action" er huket av som standard. Andre mulige verdier er: "Restrict", "Cascade", "Set null" og "Set default". Hva betyr de forskjellige, og hva anbefaler dere?

5494978[/snapback]

Kort fortalt: Dette bestemmer hva som skal gjøres dersom det med en fremmednøkkel når det skjer noe med raden fremmednøkkelen peker på. Hvis du har en tabell med kunder, KudneNr er primærnøkkel. Du har en tabell UtLeideFilmer med en fremmednøkkel KundeNr som peker på KundeNr i tabellen kunder. Hva skal skje med de radene i UtLeideFilmer når du gjør endring/sletter en rad i kunder? Skal det:

 

"Restrict"es? Antar: Nekte oppdateringen.

"Cascade"? Hvis en kunde slettes, skal da også utleieinformasjon slettes?

"Set null"? Sette null i foreign key

"Set default"? Sette defaultverdi i foreign key (Jeg mener at denne ved oppdatering vil føre til at den oppdaterte verdi av pk settes inn i fk, men er ikke sikker)

[remi sture]

Tusen takk for tilbakemeldinger. Men jeg sliter fortsatt med "circular relations". Noen som har peiling på hvor dette er? Feilmeldingen sier ikke noe om det nemlig...

[remi sture]

Hei igjen!

 

Kommer ingen vei med denne jeg, får bare beskjed om at det er "circular relations", så jeg tenkte jeg skulle forklare hver klasse og relasjon litt bedre for dere:

 

season - Har kobling mot flere andre tabeller. Her registreres en ny sesong, f.eks 2006. (Har dere en bedre måte å gjøre det på?)

 

department - Et lag i intraTeams kan kun være i én department, men én department kan inneholde flere intraTeams. Dette er altså en avdeling, f.eks blir Gutter Elite plassert i Ungdomsavdelingen.

 

intraTeams - Dette er interne lag i denne klubben jeg lager dette systemet for, f.eks A-lag, juniorlag og guttelag. Blir koblet opp mot department.

 

coach - Inneholder informasjon om de forskjellige trenerne som skal lagres i systemet.

 

teamAndCoach - Her kobler jeg sammen trenere og lag, via coach, intraTeams og season. Meningen er at en trener da kan være involvert i forskjellige lag, i forskjellige sesonger.

 

player - Inneholder informasjon om de forskjellige spillerne som skal lagres i systemet.

 

teamAndPlayer - Her kobler jeg sammen spillere og lag, via player, intraTeams og season. Meningen er at en spiller da kan være involvert i forskjellige lag, i forskjellige sesonger.

 

boardType - Inneholder navnet på de forskjellige styrene.

 

boardAndMembers - Bruker season_id og boardMebers_id til å knytte sammen styremedlemmene, sortert etter sesong og type.

 

boardMembers - Inneholder informasjon om de forskjellige styremedlemmene som skal lagres i systemet.

 

matchType - Blir brukt av tabellen match, og kan inneholde f.eks. treningskamp, seriekamp, turnering.

 

stadium - Inneholder informasjon om de forskjellige stadionene som skal lagres i systemet. Blir brukt som fremmednøkkel i match.

 

match - Her registreres hver enkelt kamp. matchType og stadium er som sagt fremmednøkler. I tillegg bruker jeg intraTeams og season som fremmednøkler for å kunne hente ut et lags kamper, sortert etter sesong.

 

matchStats - Her brukes player og match som fremmednøkler for å lagre statistikker for hver spiller etter hver kamp. start og out er meningen skal inneholde minuttet hvor spilleren blir byttet inn og ut, f.eks 0 og 90 (er det bedre å bare ha et felt som lagres antall minutter spilleren eventuelt spiller, og bare drite i innbytte-greiene?)

 

leagueTab - Dette er tabelloversikten for et intraTeam sortert etter sesong, slik at man kan bla seg tilbake og se 4 år gamle tabeller. I team skal motstanderlaget registreres. I utganspunktet vurderte jeg å generere tabeller automatisk utifra matches, men droppet det da man da må registrere hver eneste kamp for alle lagene for hver serierunde. Bør jeg ha med en points-attributt her også, eller skal jeg regne det ut via PHP?

 

links - Dette har ingenting med resten av systemet og gjøre. Skal være en lenke-samling på nettsiden, hvor lenkene er plassert i forskjellige kategorier.

 

linksCategory - Kategoriene hvor linkene skal plasseres.

 

 

http://remisture.no/diverse/datamodell.png - Bilde av datamodellen!

http://remisture.no/diverse/datamodell.xml - Arbeidsfil i DBDesigner 4

 

 

Håper noen hadde giddet å se over dette, da jeg tydeligvis ikke kommer noe vei selv. På forhånd takk!

[___]

Heisann!

 

Har sittet i mange timer her nå og forsøkt å komme fram til en fornuftig datamodell for et kommende prosjekt jeg har på gang, og trenger nå innspill fra dere på hva jeg kan endre på i førsteutkastet. Noe som mangler, bør endres eller droppes?

 

Dette er, som dere kanskje skjønner, altså at system for en fotballside, hvor jeg skal registrere lag, spillere, trenere, kamper, tabeller, og styremedlemmer, for å nevne noe.

 

Cluet er at jeg vil at spillere og trenere og slikt skal kunne legges til i flere sesonger (f.eks 2003,2003,2004) og flere lag (en spiller kan spille på juniorlaget og A-laget, f.eks), slik at jeg kan registrere statistikker over flere år. Er dette mulig slik det er satt opp nå?

 

Bør jeg flytte address, phone, cell og slikt over i en egen tabell, eller er det ikke vits i når det ikke er snakk om mer enn noen hundre personer som skal registreres?

 

I relasjons-editoren i DBDesigner 4 kan man velge hva som skal skje ved sletting og oppdatering (on delete, on update), hvor "No action" er huket av som standard. Andre mulige verdier er: "Restrict", "Cascade", "Set null" og "Set default". Hva betyr de forskjellige, og hva anbefaler dere?

 

Må man forresten bruke InnoDB som tabelltype når man bruker fremmednøkler?

 

http://remisture.no/diverse/datamodell.xml -> arbeidsfil fra programmet DBDesigner 4

 

5494978[/snapback]

 

Jeg har tittet litt på datamodellen din, og noe av det første som slår meg er at du benytter enkelte reserverte ord som feltnavn. Kanskje dette går bra i MySQL, men i Oracle gikk det ikke bra da jeg prøvde å lage databasen der. Et eksempel er feltet TIME i MATCHES-tabellen. De to andre er START og OUT i MATCHSTATS-tabellen.

 

Ellers er jeg enig i det som tidligere er sagt om å lage en egen person-tabell, slik at alle tabeller som i dag har persondata i seg, heller refererer til en egen person-tabell.

 

Når det gjelder circular relations, så har jeg importert basen din i et annet modelleringsverktøy, og kjørt en "helsesjekk" på den. Ingen problemer der.

 

Werner

[remi sture]

Takk for tilbakemelding!

 

Er det mulig at jeg har sittet i to dager å irritert meg over en feil som gjerne bare er en bug i DBDesigner? *Grøss* Var det via xml-filen du importerte dette?

Endret 26. januar 2006 av remi sture

[___]

Takk for tilbakemelding!

 

Er det mulig at jeg har sittet i to dager å irritert meg over en feil som gjerne bare er en bug i DBDesigner? *Grøss* Var det via xml-filen du importerte dette?

5503078[/snapback]

 

Jeg åpna xml-fila i DBDesigner, og så kjørte jeg en eksport til SQL-setninger. Byttet bl.a. ut MySQL-datatypene som Oracle ikke takler. Så importerte jeg scriptet i et annet modelleringsverktøy. Ingen problemer.

 

Werner

[remi sture]

Jeg burde vel gjerne nevnt at den feilmeldingen kun kommer når jeg huker av "Export selected tables only". Er det rett og slett så dumt at programmet ikke takler det hvis ingen tabeller er merket?

[martinslange]

Heisann!

 

tusen takk for tilbakemelding, men jeg må få fikset følgende feilmelding først:

 

"There are circular relations"!

 

Men jeg får ikke beskjed om HVOR dette er. Jeg har sett meg blind på dette nå.

 

http://remisture.no/.../datamodell.png

http://remisture.no/.../datamodell.xml - Åpnes i DBDesigner 4

 

.

Endret 11. april 2013 av martinslange

[oldis]

Heisann,

 

.... du har hele 3 tabeller med personinfo? Hvorfor ikke slå sammen både trenere, styremedlemmer og spillere i samme tabell? Ikke vet jeg, men teoretisk kan vel både dommere eller i alle fall spillere sitte i et styre, og/eller status kan forandre seg? Ved hjelp av en liten kode i en persontabell kan du legge inn aktuell status for hver hver person, f.eks. om vedkommende er spiller, styremedlem og/eller dommer?

 

 

Litt på siden, men noen her er sikkert nerdete nok til å finne det interessant:

 

Å gjøre det slik er kjekt i sånne sammenhenger.

1=Spiller

2=Dommer

4=Styremedlem

8=Trener

16=Materialforvalter

 

Du lagrer tallet som er summen av de som gjelder for en spesifikk person.

Spiller+trener = 9

 

Du kan lage dine egne funksjoner erDommer() erSpiller() etc. eller du kan lage en array som inneholder alle verv for en person.

 

Veldig raskt. Minuset er at det er vanskelig å holde styr på dersom du har veldig mange i lista, da kan tallet fort bli veldig stort.

 

EDIT:

Oisan.

Så nå at dette var en veldig gammel tråd. OP kan være avgått for alt jeg vet.

Beklager...

Endret 26. april 2013 av oldis