Ik heb een klein advies nodig van jullie.
Ik ben bezig met een programma waarin artikelen staan onder een merk en/of merkserie. Niet zo spannend. Een artikel heeft bepaalde specificaties welke altijd dynamisch zijn. Dus in principe staat nooit iets vast. Ik zou daarom willen weten of jullie een beter idee hebben voor het volgende (normaal gebruik ik andere naamgevingen, maar zo is het even voor iedereen duidelijk):
Alleen is bovenstaande niet helemaal goed omdat ik niet weet welke type (varchar, int, enum, etc..) ik moet gebruiken bij een kolom in artikel_type_specificatie_waarde omdat dit niet bekent is op deze manier. Dus ik zal hier dan bijv een varchar(100) ofzo moeten gebruiken om alles te kunnen afvangen. Dat betekent ook dat ik 100 karakters reserveer voor bijvoorbeeld een waarde dat altijd 1 of 0 is..
Dus misschien iemand een beter idee? Of moet ik het duidelijker uitleggen. Alvast bedank!
Wat ik begrijp is dat de specificatie echt dynamisch is per artikel type. Dat betekend dat je 2 tabellen minder krijgt.
De tabellen artike_type_specificatie_waarde en artikel_type_specificatie kunnen sowiezo al samen, het heeft geen meerwaarde dit te splitsen.
Als mijn 1e veronderstelling juist is, dan heeft eenzelfde type altijd een bepaalde vaste waarde. Dus kan je de specificatie ook bij de artikel_type tabel plaatsen.
Dat betekent ook dat ik 100 karakters reserveer voor bijvoorbeeld een waarde dat altijd 1 of 0 is..
Even los van het feit dat VARCHAR niet het goede type is voor een waarde die alleen 1 of 0 kan zijn;
Bij een type VARCHAR reserveert MySQL de ruimte niet van te voren. De ruimte wordt pas gebruikt als het veld daadwerkelijk gevuld wordt. Als je dus een veld VARCHAR 255 maakt ben je niet per record 255 bytes kwijt. Het hangt er van af wat er in het veld staat.
Lege velden moet je niet meerekenen wanneer je het over redundantie krijgt. Lege velden nemen geen ruimte in, en ook voor je snelheid van de datbase is dat niet nadelig.
Als je geen lege velden mag hebben, waarom heb je dan de mogelijkheid tot optionele velden? ;)
Jou eerste opzet is te ver uit elkaar getrokken om die lege velden heb ik het idee. Als behalve de lege velden, de specificaties per type anders zijn, dan moet je dit gewoon in de type tabel zetten.
(tenminste, zo heb ik het geleerd met normaliseren, maar ik heb ook wel eens gehoord dat daar ook weer verschillend over wordt gedacht)
Jan: Bij bijvoorbeeld een CHAR wordt dit toch wel gereserveerd, bij VARCHAR is dit idd niet zo.. ( het verschil tussen bijv. een CHAR en VARCHAR ).
Robert: Klopt jou manier kan ook, maar ik heb het dus zo geleerd dat je het beter uit elkaar kan trekken voor eventuele uitbreidingen, uitgebreide selecties, etc.. Maar de korte manier lost wel mijn probleem op. Ik zal er dus nog even over nadenken.
Robert: Hoe wil je bijvoorbeeld alle specificaties ophalen van een type waaraan een artikel is gekoppeld op jou manier zonder te maken te krijgen met specifictaies waarmee een bepaalde artikel niks mee te maken heeft?
Daarom stelde ik ook vragen in mijn antwoorden. (klinkt leuk) of de type specificaties voor ieder artikel of voor ieder type uniek zijn. Dan heb je er geen last van, met zoeken.
Als een artikel niet aan bepaalde specificaties gezochte specificaties voldoet:
bijv WHERE specificatie LIKE '%green%' (slechts een voorbeeld)
dan geeft die ook alleen artikelen die daaraan voldoen.
Specificaties gelden voor de type.. een artikel heeft een type en het probleem ligt dus bij het opslaan van deze specificatie waardes welke gekoppeld zijn aan het artikel via de type.
Stel ik moet dan een artikel weergeven:
Artikel 1
Artikelnaam : naam
Type: type 1
Specificatie_3 : waarde
Specificatie_4 : waarde
Specificatie_6 : waarde
Specificatie_7 : waarde
Artikel 2
Artikelnaam : naam
Type: type 2
Specificatie_2 : waarde
Specificatie_5 : waarde
Specificatie_10 : waarde
Specificatie_11 : waarde
Een beeldscherm heeft andere specificaties dan een toetsenbord..
