[Database Ontwerp]

[thomaske]

Hallo,

Ik ben bezig met een database ontwerp voor een online-shop. Dit heb ik tot nu toe. Het is nog erg summier, maar het gaat op dit moment even om het opslaan van verschillende waarden van verschillende attributen. Zodat je per productgroep bepaalde attributen hebt (bijv. rpm bij harddisks en kloksnelheid bij processoren)

Hieronder het ERD:


Is het opslaan van de gegevens op deze manier handig? Wanneer ik nu bijvoorbeeld alle attributen (met waarden) van alle producten uit een bepaalde groep wil hebben krijg ik zoiets:

code:

productID  productname     price   attributename  attributevalue  
-----------------------------------------------------------------
1       AthlonXP 1800+  150     kloksnelheid   1800 Mhz 
1       AthlonXP 1800+  150     cache       128 kb 
2       AthlonXP 1600+  125     kloksnelheid   1600 Mhz 
2       AthlonXP 1600+  125     cache       128 kb

voor elke attribuut dus een aparte record. Niet echt een probleem, maar is er een andere/betere oplossing zodat eventueel alle attributen van een bepaald product in 1 record komen?
bedankt!

[Verwijderd]

Ik zou dus gewoon 3 tables maken:

productgroep (bijv procs, memory, HD etc.)
product (naam, prijs, snelheid/hoeveelheid etc.)
attribuut type (o.i.d) (kloksnelheid/cache/Ram etc.)

[thomaske]

Op vrijdag 01 februari 2002 19:23 schreef Donkey het volgende:
Ik zou dus gewoon 3 tables maken:

productgroep (bijv procs, memory, HD etc.)
product (naam, prijs, snelheid/hoeveelheid etc.)
attribuut type (o.i.d) (kloksnelheid/cache/Ram etc.)

maar het is de bedoeling dat je per productgroep theoretisch een oneindig aantal attributen kan maken..

[whoami]

Ik vind jouw oplossing zo mis niet.

[Access]

Ik snap de ballen van jouw plaatje .

Ik zou het (ongeveer) zo doen:

code:

PROD_ID, ATTR, PROD_NAME, PROD_PRICE
         |
   |-------|
   |
ATTR_ID, ATTR_NAME

PROD_ID = Primary Key
ATTR = Foreign Key
ATTR_ID = Primary Key


BV:

code:

Id (PROD_ID) - Product (PROD_NAME,ATTR_NAME) - Price (PROD_PRICE)
-----------------------------------------------------------------
1       - AthlonXP 1600+, 128Kb Cache   - EUR 200,-

En de query zou hierbij kunnen zijn:
SELECT *
FROM products p, attributes a
WHERE p.attr = a.attr_id;


Correct me if im wrong....

[thomaske]

Op vrijdag 01 februari 2002 19:46 schreef Access het volgende:

Ik zou het (ongeveer) zo doen:
...

Correct me if im wrong....

nu bepaal je per product welke attributen je hebt, maar ik wil dat per productgroep. Dus van alle harddisks wil ik weten wat de capaciteit is en hoe snel ze ronddraaien en van de processoren hoe snel ze zijn en wat bijvoorbeeld hun cache is.. snaptu?

[Access]

Hmm, als ik het zo lees is het onmogelijk. Hoe wil je dat doen ? Een pentium III heeft meer cache dan een duron. Dus ?

[Verwijderd]

Als je nou een tabelletje maakt met attributen, 1 tabelletje met producten en één koppeltabelletje dat bestaat uit twee keys.

vrij eenvoudig:

code:

products:
product_id(key), product_name, etc

attribs:
attrib_id(key), attrib_name, etc

products_attribs:
product_id(key), attrib_id(key)

products_attribs is het organische tabelletje dat zorgt dat je oneindig veel attributen aan je product kan hangen.

[Killemov]

Ehm, gebruik maken van geneste groepen is meestal vragen om problemen. (In SQL is het nog steeds niet mogelijk om bij bijvoorbeeld met de tabel persoon en een ouder-kind relatie te vragen: geef mij alle kleinkinderen van persoon X)

[thomaske]

Op vrijdag 01 februari 2002 19:59 schreef Access het volgende:
Hmm, als ik het zo lees is het onmogelijk. Hoe wil je dat doen ? Een pentium III heeft meer cache dan een duron. Dus ?

De attribuut-namen zijn voor iedere productgroep verschillend. Maar binnen dezelfde productgroep beschik je dus over dezelfde attributen, MAAR ieder product heeft wel zijn eigen waarden voor dat attribuut. Is het nog duidelijk?

[Access]

Ehm, nee, eigenlijk niet. Het kan aan de tijd liggen, al lijkt me dat erg onwaarschijnlijk. Misschien helpt het als je iets tekent ofzo, waarin je aangeeft wat waarbij hoort ?

[thomaske]

Op zaterdag 02 februari 2002 00:01 schreef Access het volgende:
Ehm, nee, eigenlijk niet. Het kan aan de tijd liggen, al lijkt me dat erg onwaarschijnlijk. Misschien helpt het als je iets tekent ofzo, waarin je aangeeft wat waarbij hoort ?

heel simpel:

de namen van de attributen zijn afhankelijk van de groep waartoe het product behoort.
_{(bijvoobeeld: kloksnelheid, opslagruimte, toegangstijd)
dit is dus table tblAttributes}

de waarden van de attributen zijn afhankelijk van het product.
_{(bijvoorbeeld: 1800 Mhz, 40GB, 15ns)
dit is dus table tblAttrValues}

[Verwijderd]

/me heeft het gelezen en er begint wat te borrelen

Als je nou een tabel hebt met het product zelf. Daarin geef je met een foreign key de productgroep aan (de tweede tabel). De derde tabel wordt een tabel met de eigenschappen/attributen voor een bepaald artikel. Maak dan een extra link tabel waarbij je de combinatie productgroep_id <-> attribuut_id maakt Deze linktabel kan je dan gebruiken in een join om van een productgroep de attributen op te halen... Dan kan je een attribuut dus ook direct in meerdere productgroepen terug laten komen

[whoami]

Op vrijdag 01 februari 2002 21:16 schreef Killemov het volgende:
Ehm, gebruik maken van geneste groepen is meestal vragen om problemen. (In SQL is het nog steeds niet mogelijk om bij bijvoorbeeld met de tabel persoon en een ouder-kind relatie te vragen: geef mij alle kleinkinderen van persoon X)

Hoezo? Ik heb al verschillende databases geimplementeerd met self-joins en nog nooit problemen gehad.
Het is juist de bedoeling van een self-join om een ouder-kind relatie te kunnen opvragen.

[oZy]

Op zaterdag 02 februari 2002 00:13 begon er bij pingiun wat te borrelen

nu kan ieder product maar 1 attribuut hebben.

lees deze topic maar even door, soortgelijk ontwerp:

[topic=354153/1/25]

[Orphix]

Op zaterdag 02 februari 2002 03:48 schreef oZy het volgende:
nu kan ieder product maar 1 attribuut hebben.

nee hoort, tblAttrValues is een koppeltabel. Voor elk produkt kan een attribuut van die categorie wel of niet opgeslagen worden.

Ik geloof dat iedereen hier zelf probeert een db model te maken, maar ik zie eigenlijk geen fouten hierin. Ik heb een tijdje geleden namelijk zowat precies hetzelfde ontworpen

Gewoon hiermee doorgaan dus

[oZy]

Op zaterdag 02 februari 2002 04:10 schreef Orphix het volgende:

[..]

nee hoort, tblAttrValues is een koppeltabel. Voor elk produkt kan een attribuut van die categorie wel of niet opgeslagen worden.

Ik doelde op de oplossing van pinguin, niet op het orginele model van thomaske.

[Verwijderd]

1 AthlonXP 1800+ 150 kloksnelheid 1800 Mhz
1 AthlonXP 1800+ 150 cache 128 kb

On a side note:

Hier staat twee maal hetzelfde attribuut beschreven voor één product. Dat is redundante data en dat moet je mijden als de pest.

[whoami]

Op zaterdag 02 februari 2002 10:26 schreef ManiaXe het volgende:

[..]

On a side note:

Hier staat twee maal hetzelfde attribuut beschreven voor één product. Dat is redundante data en dat moet je mijden als de pest.

Die data is niet redundant, want die Athlon XP dinges wordt geen 2 x opgeslagen maar slechts 1x.
Hetgeen jij toont is waarschijnlijk het resultaat van de query:

code:

select * from tblproduct, tblattrvalues 
where tblproduct.productid = tblattrvalues.id

Het opslaan van redundante data kan trouwens soms voordelen hebben ivm performance.

[thomaske]

Op zaterdag 02 februari 2002 10:26 schreef ManiaXe het volgende:

[..]

On a side note:

Hier staat twee maal hetzelfde attribuut beschreven voor één product. Dat is redundante data en dat moet je mijden als de pest.

Dit is inderdaad niet redundant. Maar omdat er voor het product 2 records zijn in de AttrValue tabel worden de de productgegevens ook tweemaal weergegeven!

[Access]

Zeg thomaske, wil het al een beetje lukken ? (ben bestwel benieuwd, en zo ja waar kunnen we het resultaat bewonderen ? )

[thomaske]

Op zaterdag 02 februari 2002 15:46 schreef Access het volgende:
Zeg thomaske, wil het al een beetje lukken ? (ben bestwel benieuwd, en zo ja waar kunnen we het resultaat bewonderen ? )

Nja.. met het huidige db-model lukt het wel hoor.. (ben alleen benieuwd naar verdere aanpassingen/normalisaties).
Er is nog nergens resultaat te zien.. (t'is ook nog niet in die staat dat het voor anderen iets nuttigs te bieden heeft )

Maar ik ben nu bezig met de implementatie van de parent-child relatie van de verschillende productgroepen..