Toon posts:

[Alg] Database archiveren?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Lectori Tweakeri salutem,

Tijdens het ontwikkelen van een systeem voor een (willekeurige) sportvereniging liep ik tegen het volgende probleem. De taal (php) en dbms (mysql) maken volgens mij niets uit voor de oplossing. Het gaat mij meer om het waarom en het duwtje in de goede richting.

De database bevat tot nu toe zo'n 30 tabellen (leden, teams, wedstrijden, scheidsrechters, coaches, spelers, spelerseigenschappen, enz.)
Om aan te geven hoe ik het op dit moment doe. Men kan per lid instellen 'dit is een speler'. Op dat moment wordt er een record toegevoegd aan de tabellen `spelers` (id, lid_id, ingedeeld) en `spelerseigenschappen` (id, lid_id, team_id, positie, kledingmaat, enz.). Op het moment dat een speler wordt ingedeeld in een team, worden de `spelerseigenschappen` aangepast met het juiste team. Ik heb voor deze manier gekozen, zodat een lid wel de spelerstatus kan verliezen, maar niet z'n eigenschappen. Kan waarschijnlijk beter/logischer, door de status ook op te nemen in de tabel `spelerseigenschappen`, maar dat even terzijde.

Aan het einde van het speelseizoen (of het begin van het nieuwe seizoen) zullen de teams aangepast moeten worden. Nieuwe spelers en teams komen erbij en de teamindeling verandert (spelers 'promoveren' bijvoorbeeld). Op dit moment komt het probleem; van oude wedstrijden moet je ook kunnen zien welk team er heeft gespeeld en wie er op dat moment in dat team zaten. Je kan dus niet zomaar de teams in de database aanpassen, want dan krijgen oude wedstrijden ook die nieuwe eigenschappen. Nu kunnen spelers niet toegevoegd worden in een team, als ze al zijn ingedeeld in een ander team. Hoe kan ik dit probleem het best aanpakken? Nieuwe teams maken en de oude gegevens op een bepaalde manier wegschrijven? M.a.w. voor het huidige seizoen alles op de huidige manier bijhouden en zodra een seizoen is afgelopen alle gegevens van dat seizoen exporteren (xml?) of omzetten naar een archief (mysql) database?

  • BtM909
  • Registratie: Juni 2000
  • Niet online

BtM909

Watch out Guys...

Da's een bekend probleem die velen vast hebben gehad bij de "Maak een kassasysteem in Access" schoolopdracht :)

Eigenlijk had je dus in de wedstrijd tabel ook de namen bij moeten houden die meededen. Doe je dat nu niet, dan zou je wellicht een export kunnen maken (andere db), die niet meer te wijzigen is.

[ Voor 5% gewijzigd door BtM909 op 13-02-2004 15:08 ]

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.


  • Jaspertje
  • Registratie: September 2001
  • Laatst online: 18-05 15:53

Jaspertje

Max & Milo.. lief

[ranz mode]
Database kopieeren voor het nieuwe seizoen en oude bewaren
[/ranz mode]

Heb je niet ergens een tabel seizoen die door de hele database als mieren zit?
Zodat je bij een nieuw seizoen alles in diezelfde tabellen kopieert met een nieuw seizoenID

eg:
tabelSpelers 
spelerIDSpeler_naam
  
tabelSeizoenen 
SeizoenIDSeizoenNaam
  
tabelSpeler per seizoen 
SpelerIDSeizoenID


Volgens mij ligt het dus wel aan de dmbs, maar dan aan het model.. die laatste tabel, daar zou veel meer inkomen, veel meer wat bij dat seizoen hoort dan..

Maar ik weet niet of je hier nog wat aan hebt nu...

[ Voor 13% gewijzigd door Jaspertje op 13-02-2004 15:13 ]


  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 00:04

ripexx

bibs

De database opzet is eigenlijk niet geheel goed genormaliseerd. Ik heb hetzelfde probleem ook gehad. Mijn opzet is als volgt:

De volgende tabellen heb ik:
Seizoenen (seizoen_id, start, eind, oms)
Teams (team_id, seizoen_id, naam, cat, enz. enz.)
Wedstrijden (wedstrijd_id, team_id, tegenstander_id, datum, tijd, uitslag, veld, opm enz.)
Tegenstanders (tegenstander_id, naam, omschrijving, telefoon, route, etz.)
Leden (lid_id, naam, geb_dat, is_coach, is_trainer, enz)

Koppeltabellen
leden_team (lid_id, team_id)
team_coach (lid_id, team_id)
team_trainer (lid_id, team_id)

Dit is het wedstrijd gedeelte, daarnaast zijn er nog teamnotes, usernotes, rechten opties, nieuwsitems, polls, forum etc. Alle bij elkaar heb ik nu zón 60 tabellen.

buit is binnen sukkel


Verwijderd

Topicstarter
BtM909 schreef op 13 februari 2004 @ 15:08:
Da's een bekend probleem die velen vast hebben gehad bij de "Maak een kassasysteem in Access" schoolopdracht :)
Bij dat probleem maakten we toen iedere week een nieuwe tabel aan ;) Is trouwens een iets kleinere en fictievere opdracht dan dit.
Eigenlijk had je dus in de wedstrijd tabel ook de namen bij moeten houden die meededen. Doe je dat nu niet, dan zou je wellicht een export kunnen maken (andere db), die niet meer te wijzigen is.
Hoe bedoel je dit precies? In plaats van "het spelende team -> leden in dat team -> leden" bijhouden dus bij iedere wedstrijd zeggen welke spelers er mee doen? Volgens mij is dit voor de beheerder een niet zo'n prettig gegeven. Overuren++; Is je database normalisering dan ook niet een beetje gaar geworden? Overigens hou je dan nog het probleem van het spelende team. Volgens mij ontwijk ik alle problemen als je een speler in meerdere teams kan laten spelen en na ieder seizoen een nieuwe lijst met teams aanmaakt en de oude 'verwijdert' (dus onzichtbaar maakt voor verdere bewerking). Hierdoor kan een wedstrijd gewoon aan een team_id gekoppeld blijven en kunnen binnen dat team de leden_ids gekoppeld blijven...
Jaspertje schreef op 13 februari 2004 @ 15:11:
Heb je niet ergens een tabel seizoen die door de hele database als mieren zit?
Zodat je bij een nieuw seizoen alles in diezelfde tabellen kopieert met een nieuw seizoenID
Die tabel is er nog niet inderdaad. Ik ben ook nog niet letterlijk tegen het probleem aangelopen, aangezien ik nog bezig ben met ontwikkelen en ontwerpen (of in omgekeerde volgorde :z). Naar mij idee is een database model nog niet per se af, als je begint met scripten :)
Volgens mij ligt het dus wel aan de dmbs, maar dan aan het model.. die laatste tabel, daar zou veel meer inkomen, veel meer wat bij dat seizoen hoort dan..

Maar ik weet niet of je hier nog wat aan hebt nu...
Zeker wel
ripexx schreef op 13 februari 2004 @ 15:13:
De database opzet is eigenlijk niet geheel goed genormaliseerd. Ik heb hetzelfde probleem ook gehad. Mijn opzet is als volgt:
Blijft inderdaad moeilijk om alles netjes genormaliseerd te houden, maar dat probeer ik wel zoveel mogelijk. Met een seizoenstabel erbij zou je dus veel problemen kunnen oplossen.
/me gaat z'n erd weer aanpassen :9

  • BtM909
  • Registratie: Juni 2000
  • Niet online

BtM909

Watch out Guys...

Verwijderd schreef op 13 februari 2004 @ 15:26:
[...]
Bij dat probleem maakten we toen iedere week een nieuwe tabel aan ;) Is trouwens een iets kleinere en fictievere opdracht dan dit.
[...]
Het ging meer om het feit dat de prijzen achteraf wijzigden en vervolgens ook je jaaromzet naar beneden ging 8)7

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.


  • The Eagle
  • Registratie: Januari 2002
  • Laatst online: 01:50

The Eagle

I wear my sunglasses at night

Ik heb een leuke tip voor je denk ik (overigens wel leuk om dat in SQL er helemaal bij te proggen :P ): Maak gebruik van effective dated rijen. Oftewel: maak voor iedere aanpassing of wijziging een nieuwe rij aan, waarbij je een ingangsdatum hanteert. Zo kun je bijvoorbeeld een persoon makkelijk op een bepaalde datum zijn status(sen) laten wijzigen, terwijl al zijn historische gegevens in de DB blijven staan.
Ik werk zelf met PeopleSoft (ERP-pakket mocht je dat niet weten) en dat maak hier heel sterk gebruik van. Mist je het principe goed doorhebt werkt het als een trein!
Suc6

Al is het nieuws nog zo slecht, het wordt leuker als je het op zijn Brabants zegt :)

Pagina: 1