Database artikelen advies

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Dan Me

Dan Me

02/04/2007 09:49:00
Quote Anchor link
Goeiemorgen mensen,

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
 
PHP hulp

PHP hulp

21/11/2024 22:40:28
 
Robert Deiman

Robert Deiman

02/04/2007 10:11:00
Quote Anchor link
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.
 
Dan Me

Dan Me

02/04/2007 10:28:00
Quote Anchor link
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?
 
Jan Koehoorn

Jan Koehoorn

02/04/2007 10:36:00
Quote Anchor link
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.
 
Robert Deiman

Robert Deiman

02/04/2007 10:36:00
Quote Anchor link
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)
 
Dan Me

Dan Me

02/04/2007 11:01:00
Quote Anchor link
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.

Bedankt in iedergeval!
Gewijzigd op 01/01/1970 01:00:00 door Dan Me
 
Dan Me

Dan Me

02/04/2007 11:03:00
Quote Anchor link
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?
 
Robert Deiman

Robert Deiman

02/04/2007 11:09:00
Quote Anchor link
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.
 
Dan Me

Dan Me

02/04/2007 11:14:00
Quote Anchor link
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..
Gewijzigd op 01/01/1970 01:00:00 door Dan Me
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.