Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

Database model verbeteren (MYSQL)

Pagina: 1
Acties:
  • 127 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ik heb nu een internet wielrenspel(PHP) met de volgende database constructie

renners:
id,naam,id_ploeg,landcode

wedstrijd team:
id_team, id_deelnemer,id_etappe,id_renner_1, id_renner_2, enz ...(deelnemer+etappe = uniek)

etappe
id_etappe,........,uitslagrenner_1,uitslagrenner_2, enz...

Nu heb ik begrepen dat de laatste 2 oplossingen niet echt sterk zijn.maar hoe moet ik dat dan oplossen ?

Ik heb gedacht aan etappe uitslag :
id_etappe, id_renner(samen PK),plaats

maar het echte probleem zit bij het wedstrijdteam.
Als je 10 renners mag kiezen die je allemaal apart wegzet bv:
id_deelnemer,id_etappe,id_renner,plaats_in_team;
dan is de deelnemer/etappe niet meer uniek, dus extra controles bij samenstellen en wijzigen team , wat nu met een insert in 1 rij gebeurt moet dan over meerdere rijen gebeuren.

Bovendien krijg je 10 keer zoveel rijen in de database.

Zie ik beren op de weg ?

  • Michali
  • Registratie: Juli 2002
  • Laatst online: 05-11 19:33
Je krijgt dan idd. extra tabellen, namelijk wedstrijdrenners en etapeuitslagen. deelnemer/etappe/renner is dan wel uniek, dit wordt dan je primary key. Als je met genummerde velden gaat werken, dan is het vrijwel altijd beter om hier een aparte tabel van te maken. Behalve als het slechts enkele zijn waarvan het aantal nooit kan veranderen. In dit geval zie ik best kans dat het aantal wel eens zou kunnen veranderen, en dan zou ik het data model zo ontwerpen dat je hier geen problemen bij kan verwachten.

Noushka's Magnificent Dream | Unity


Verwijderd

Normalisatie is in dit geval wel het beste ja, koppeltabellen gebruiken. Als je een extra iets wilt toevoegen of verwijderen hoor je daar nooit de structuur bij te veranderen, dan zit je fout. Dan bedoel ik dus bijvoorbeeld een extra categorie toevoegen of in dit geval meer renners of minder.

  • Jaap-Jan
  • Registratie: Februari 2001
  • Laatst online: 11:32
Michali schreef op donderdag 08 november 2007 @ 12:31:
Je krijgt dan idd. extra tabellen, namelijk wedstrijdrenners en etapeuitslagen. deelnemer/etappe/renner is dan wel uniek, dit wordt dan je primary key. Als je met genummerde velden gaat werken, dan is het vrijwel altijd beter om hier een aparte tabel van te maken. Behalve als het slechts enkele zijn waarvan het aantal nooit kan veranderen. In dit geval zie ik best kans dat het aantal wel eens zou kunnen veranderen, en dan zou ik het data model zo ontwerpen dat je hier geen problemen bij kan verwachten.
Al met al heeft dit te maken met normalisatie. Die genummerde velden zijn in dit datamodel een repeterende groep. Misschien is het handig om een tutorial databasenormalisatie door te lezen. :)

En een andere opmerking: ik zie niet duidelijk hoe de relaties liggen in je datamodel. Wat is een deelnemer (in verband met deelnemer_id) en waarin verschilt die van een 'renner' (renner_id)? En wat is het verschil tussen een 'ploeg' (ploeg_id) en een 'team' (team_id)? En als 'deelnemer' en 'ploeg' ook aparte entiteiten zijn, waarom zie ik ze dan niet terug in je datamodel? :)
Verwijderd schreef op donderdag 08 november 2007 @ 12:53:
Normalisatie is in dit geval wel het beste ja, koppeltabellen gebruiken. Als je een extra iets wilt toevoegen of verwijderen hoor je daar nooit de structuur bij te veranderen, dan zit je fout. Dan bedoel ik dus bijvoorbeeld een extra categorie toevoegen of in dit geval meer renners of minder.
Koppeltabellen zijn toch alleen noodzakelijk bij veel-op-veel relaties? Volgens mij zijn de meeste relaties in deze database één-op-veel en dan kun je dus gewoon foreign keys gebruiken.

[ Voor 19% gewijzigd door Jaap-Jan op 08-11-2007 13:02 ]

| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett


Verwijderd

Je hebt gelijk, ik gebruikte de verkeerde term. Gewoon foreign keys ja.

Verwijderd

Topicstarter
Ik heb niet alle tabellen genoemd, alleen die waar ik problemen had.
deelnemer en ploeg zijn aparte entiteiten.

<edit>
Nu heb ik dit :
deelnemer = deelnemer aan spel (persoonsgegevens)
etappe = etappe ,wedstrijd ( afstand,datum, beschrijving,startplaats , finishplaats , uitslag )
wedstrijd = ronde (naam, periode)
renner = renner, ploeg (rennersgegevens)
ploeg = ploeg met diverse renners (naam , ploegleider)

moet dus bijkomen:
uitslag = renner, etappe, plaats_in_wedstrijd
team ( renners per deelnemer per dag ) = etappe, renner, deelnemer, plaats_in _team ?

relaties middels wedstrijd_id,deelnemer_id,ploeg_id,renner_id.
Of sla ik dan de plank mis

[ Voor 71% gewijzigd door Verwijderd op 08-11-2007 13:51 ]


  • Jaap-Jan
  • Registratie: Februari 2001
  • Laatst online: 11:32
Dat ziet er goed uit op die manier, volgens mij helemaal niets mis mee. :)

| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett

Pagina: 1