Normalisatie
ik wil een database aanleggen voor de muziekgroep waarin ik speel. We willen:
1) informatie over de leden in de database steken (+wachtwoord voor authenticatie)
2) al onze bezittingen inventariseren zoals:
- truien
- schoenen
- instrumenten
3) bijhouden welk lid welk instrument / trui / ... heeft
4) een geschiedenis bijhouden van wie wat wanneer heeft gehad
Actieve leden hebben normaal altijd een trui, schoenen en een instrument maar, tussen onze ledenlijst zitten ook ex-leden (= status niet actief) zei hebben ooit spullen gehad maar toen ze stopten zijn deze naar iemand anders gegaan.
Ik maakte volgende db-structuur*, heeft iemand nog tips over de normalisatie?
*
Alvast bedankt,
Jasper
Gewijzigd op 29/05/2013 21:27:01 door Jasper DS
Ik zou per koppeling een koppel tabel maken en daarin een begin en einddatum zetten. (Het kan toch ook zijn dat een trui een tijdje bij niemand is)
Jasper DS op 29/05/2013 21:26:42:
ik wil een database aanleggen voor de muziekgroep waarin ik speel. We willen:
1) informatie over de leden in de database steken (+wachtwoord voor authenticatie)
2) al onze bezittingen inventariseren zoals:
- truien
- schoenen
- instrumenten
3) bijhouden welk lid welk instrument / trui / ... heeft
4) een geschiedenis bijhouden van wie wat wanneer heeft gehad
Actieve leden hebben normaal altijd een trui, schoenen en een instrument maar, tussen onze ledenlijst zitten ook ex-leden (= status niet actief) zei hebben ooit spullen gehad maar toen ze stopten zijn deze naar iemand anders gegaan.
1) informatie over de leden in de database steken (+wachtwoord voor authenticatie)
2) al onze bezittingen inventariseren zoals:
- truien
- schoenen
- instrumenten
3) bijhouden welk lid welk instrument / trui / ... heeft
4) een geschiedenis bijhouden van wie wat wanneer heeft gehad
Actieve leden hebben normaal altijd een trui, schoenen en een instrument maar, tussen onze ledenlijst zitten ook ex-leden (= status niet actief) zei hebben ooit spullen gehad maar toen ze stopten zijn deze naar iemand anders gegaan.
Wat je eigenlijk moet doen is je vraagstelling vertalen in tabellen:
Dus (1) ik heb leden van de band;
tabel leden: lid_id, naam, etc.
(2)
tabel bezittingen: bezitting_id, bezitting_name
(3)
tabel lid_heeft _bezitting: lid_id, bezitting_id
Als je bezittingen overdraagbaar wilt hebben, heb je de koppeltabel nodig.
tabel bezittingen: id, name, description etc
tabel koppeltabel: id, user_id, product_id, start_date, end_date etc (aan de hand van start_date en end_date kun je zien of het lid ze nog heeft etc, eventueel kun je dit uitbreiden met een 'active' veld)
Gewijzigd op 30/05/2013 20:55:24 door Joakim Broden
En de stomste 'fout' die altijd gemaakt wordt is om maar altijd een pk kolom de naam id te geven.
TJVB, jij zou dis een KOPPEL_TRUI en een KOPPEL_INSTRUMENT tabel maken? En aan die koppeltabel een startdatum en een einddatum toevoegen?
Ger en Hertog, jullie zouden 1 tabel bezittingen maken en daar alle soorten insteken? En dan één koppeltabel en einddatum.
Wat ik eventueel zou kunnen doen is een user STOCK aanmaken waaraan ik de bezittingen hang die niemand gebruikt. Het moeilijke aan de tabel bezittingen is dat dit inderdaad gaat voor een trui of een schoen maar een instrument heeft niet dezelfde waardes dus dat wordt dan sowieso een aparte tabel.
Gewijzigd op 30/05/2013 22:49:09 door Jasper DS
Ger van Steenderen op 30/05/2013 22:44:35:
En de stomste 'fout' die altijd gemaakt wordt is om maar altijd een pk kolom de naam id te geven.
Hoezo is dat fout? Ik zou zo niet 123 weten wat er fout aan is
Ik vind lid_id vind ik juist irritant en totaal overbodig. Je zit al in de tabel leden, waarom dan nog eens de een extra omschrijving lid_id, dan is id duidelijk zat.
Gewijzigd op 30/05/2013 23:20:05 door Joakim Broden
Ik had fout tussen aanhalingstekens gezet, omdat het ook niet echt fout is.
Ik heb toevallig op mijn andere scherm een query over 7 tabellen voor me, waarvan er 6 een id kolom hebben en 5 een naam kolom. Mag jij mij uitleggen hoe duidelijk alleen id dan is.
@Jasper,
Je hebt één koppeltabel op leden, bezittingen en instrumenten. Het is ongebruikelijk maar kan wel, maar dan moet je wel er voorzorgen dat de id's van bezittingen en instrumenten elkaar niet overlappen.
Je kunt uit de start- en einddatum in de koppeltabel afleiden of iets al dan niet in gebruik is, dus daar hoef je geen aparte tabel voor te maken.
Een koppeltabel heeft geen eigen id nodig, de PK is de combinatie member_id en bezitting_id
http://www.phphulp.nl/php/tutorial/overig/welke-tabellen-heb-ik-nodig-/773/
Je DB-model zou er dus anders uit zien. Verder denk ik ook niet dat die tutorial mij verder kan helpen...
en de bedoeling van de tutorial is eens een wat andere manier te laten zien ;) die heel vaak een hele snelle eerste opzet geeft die makkelijk te normaliseren is in mijn opzicht
1 tabel leden
1 tabel truien
1 tabel schoenen
1 tabel instrumenten
1 koppeltabel voor truien
1 koppeltabel voor schoenen
1 koppeltabel voor instrumenten
Normaliseren is een middel om een goed beheersbare database te verkrijgen. Het aanpassen van de database structuur als je uit de ontwikkelfase bent is not done.
Desnoods categorieën aanmaken voor kleding (vest, broek, riem, schoen, jas, sjaal, muts).
In elk geval zou ik proberen om niet per kledingstuk een koppeltabel te hebben. Dat is juist weer erg inflexibel en je zal merken dat je dan bij aanpassingen al snel een hele rij queries aan het aanpassen bent.