Database artikelen advies
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):
tabellen:
artikel
artikel_type
artikel_type_specificatie
artikel
- id
- naam
- type_id
- .....
artikel_type
- type_id
- naam
artikel_type_specificatie
- type_specificatie_id
- type_id
- naam
artikel_type_specificatie_waarde
- type_specificatie_waarde_id
- type_specificatie_id
- waarde
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!
Gewijzigd op 01/01/1970 01:00:00 door Dan Me
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.
Kan je eens een voorbeeld geven? Want op jou manier krijg je dus vaak velden die leeg zijn. Niet relationeel dus.. Of zie je het anders?
Dan schreef op 02.04.2007 09:49:
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.
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)
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.
Bedankt in iedergeval!
Gewijzigd op 01/01/1970 01:00:00 door Dan Me
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?
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.
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..
Gewijzigd op 01/01/1970 01:00:00 door Dan Me