normalisatie vraag
ik heb een vraagje omtrent normalisatie.
Ik zal het vereenvoudigd uitleggen hoe mijn database eruit ziet.
Ik heb 3 beheerstabellen (naar dit voorbeeld worden effectieve productie aanmeldingen gelogd):
- tabel1 met het artikelbestand:
ID autoint (primary key en dus aanpasbaar)
Artikelnummer (unique key)
Omschrijving
- tabel2 met mogelijke informatie die je aan een artikel kan hangen:
ID autoint (primary key en dus niet aanpasbaar)
Informatie (unique key)
Mogelijke waarden: magazijn, THT, type pallet, ...
- tabel3 waarbij men kan opgeven welke informatie er moet opgevraagd worden bij een aanmelding van een artikel:
ID autoinit (primary key en dus niet aanpasbaar)
ID_artikel
ID_info
De unique key is hier de combinatie van artikel en info.
Met deze tabel definieer je dus dat je bij artikel <x> zowel info "THT" als "magazijn" moet opvragen.
Hierboven zijn de beheerstabellen en kwa normalisatie zit dat volgens mij wel goed (nergens dubbele info gebruikt en telkens gewerkt met ID)
Ik stel mij echter de vraag of ik bij mijn HISTORIEK tabellen ook moet werken met id's of daar met de effectieve waarden?
(historiek = bij elke aanmelding wordt de nodige info opgevraagd en wordt dat weggeschreven in de historiek tabellen onder een uniek nummer in de vorm van JAAR-MAAND-VOLGNUMMER)
Bv:
historiek tabel 1 (artikel) bevat bijvoorbeeld zo'n record:
2010020001 artikel x omschrijving x
historiek tabel 2 (info artikel) bevat bijvoorbeeld volgende records:
2010020001 magazijn test (uniek nummer, info, waarde)
2010020001 THT 01/01/2011 (uniek nummer, info, waarde)
Mijn vraag: zou ik het doen zoals hierboven of zou ik in de historiek tabellen ook id's wegschrijven? (dus niet artikelnummer en omschrijving wegschrijven maar enkel de "ID"; niet de info (naam) wegschrijven maar de info id?)
Op die manier zijn mijn tabellen wel veel kleiner MAAR als ik van de ene op de andere dag mijn info "magazijn" zijn aanpassen naar "verpakking", dan zou het lijken alsof gans mijn historiek op "verpakking" zit ipv "magazijn" wat ik natuurlijk NIET wens!
Ik zou natuurlijk kunnen afblokken dat men het beheer niet meer kan wijzigen van zodra er een aanmelding op gebeurt is maar dat lijkt mij ook niet wenselijk aangezien ik dan bv artikelnummers die ik niet meer wil aanmelden niet meer kan verwijderen..
Hopelijk is het een beetje duidelijk uitgelegd en kunnen jullie mij raad geven!
Alvast bedankt.
Mvg
Ik hoop dat ik je verhaal goed begrepen heb.
Ik praat hier dus over een professioneel onderhoudsbeheersysteem inclusief boekhouding, inkoop, magazijnbeheer etc. Vergelijkbaar met SAP.
Dat is inderdaad de manier waarop je het aan zou moeten pakken. Maar die constraints kun je al afdwingen in de database zoals Midas voorstelt.
- Hoelang moet het bewaard blijven (ivm de capaciteit)
- Heeft het een relatie met de records (bij update of delete)
- Moet je dit wel opslaan in je database, files zijn makkelijker te archiveren en te beheren. Minder belasting op de DB server.
[ontopic]
Ik vind dat HISTORIEK geen relatie(Constraints) hoeft te hebben met de records.
Ook zou ik nooit een record verwijderen, maar eerder een soort status DELETED geven. Andere optie kan zijn een extra Kolom "ISDELETED" (BOOL).
Zo behoud je altijd je integriteit van je Database
Gewijzigd op 25/05/2010 22:40:32 door Andreas Warnaar