Database structuur voor artikel eigenschappen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Bart Smulders

Bart Smulders

27/01/2019 14:04:52
Quote Anchor link
Graag wil ik bij deze topic het volgende vragen.
Ik wil per artikel eigenschappen toevoegen. Rekening houdend met normalisatie.
De structuur voor de categorieën gaat als volgt.
Tabel Artikelen_Indexatie

ArtikelId MerkId Categorie Subcategorie0 Subcategorie1 Subcategorie2

Vervolgens wil ik voor elk artikel eigenschappen kunnen toevoegen.
De artikelen verschillen veel. Van Speakers naar motoren enz.
Ik heb bv een tabel Eigenschappen_kleur , Eigenschappen_ipwaarde , Eigenschappen_vorm ,enz

Op deze manier kan ik nog steeds uitbreiden/aanpassen.

Om vervolgens deze eigenschappen op een artikel toe te passen... zit ik vast daar je geen lege velden wil hebben.

Zoiets als
Tabel Artikel_AlleEigenschappen

ArtikelId Eigenschap_kleur Eigenschap_vorm Eigenschap _ipwaarde Eigenschap_mperminuut

Als dan een artikel bv geen eigenschap mperminuut heeft heb ik een leeg veld.

Hoe los ik dit het beste op?

Alvast bedankt.
 
PHP hulp

PHP hulp

24/04/2019 19:01:41
Honeypot
 
- Ariën -
Beheerder

- Ariën -

27/01/2019 14:12:33
Quote Anchor link
Je moet je database nooit nooit van eigenschappen in de breedte gaan voorzien.
Als je voor elke eigenschap een extra veld aan gaat maken, dan ben je duidelijk de verkeerde weg ingeslagen.

De enige oplossing is database-normalisatie, waarbij je in de lengte gaat werken. Eigenschappen is een eigen entiteit, en dat krijgt dus een eigen tabel. Daarin plaats je dan de alle eigenschappen die er bestaan. Aan de hand van een koppeltabel eigenschappen_artikelen kan je de ID's van de artikelen en producten met elkaar koppelen

Tabel Artikelen:
- ID (PK, Auto Increm.)
- Naam
- etc...

Tabel Eigenschappen
- ID (PK, Auto Increm.)
- Naam

Tabel Eigenschappen-artikelen
- IDeigenschap
- IDartikel

Je zou deze opzet verder uit kunnen werken in je koppeltabel als je ook met eenheden werkt.
Gewijzigd op 27/01/2019 14:13:48 door - Ariën -
 
Bart Smulders

Bart Smulders

27/01/2019 14:19:48
Quote Anchor link
- Ariën - op 27/01/2019 14:12:33:
Je moet je database nooit nooit van eigenschappen in de breedte gaan voorzien.
Als je voor elke eigenschap een extra veld aan gaat maken, dan ben je duidelijk de verkeerde weg ingeslagen.

De enige oplossing is database-normalisatie, waarbij je in de lengte gaat werken. Eigenschappen is een eigen entiteit, en dat krijgt dus een eigen tabel. Daarin plaats je dan de alle eigenschappen die er bestaan. Aan de hand van een koppeltabel eigenschappen_artikelen kan je de ID's van de artikelen en producten met elkaar koppelen

Tabel Artikelen:
- ID (PK, Auto Increm.)
- Naam
- etc...

Tabel Eigenschappen
- ID (PK, Auto Increm.)
- Naam

Tabel Eigenschappen-artikelen
- IDeigenschap
- IDartikel

Je zou deze opzet verder uit kunnen werken in je koppeltabel als je ook met eenheden werkt.



Dus moet ik per artikel in de lengte werken
Tabel
Artikel_1

ArtikelId artikeleigenschap_a artikeleigenschap_b artikeleigenschap_c


?

Dit gaat voor meer dan 50000 artikelen toch een elle lange lijst geven?

Of bezie ik het nu helemaal verkeerd?
 
Rob Doemaarwat

Rob Doemaarwat

27/01/2019 14:27:57
Quote Anchor link
- Ariën - op 27/01/2019 14:12:33:
Je moet je database nooit nooit van eigenschappen in de breedte gaan voorzien.


Ligt er aan. Als een eigenschap voor (bijna) alle artikelen geldt (bijvoorbeeld de prijs), dan kan dat natuurlijk wel in de breedte (= in de artikel tabel zelf).

- Ariën - op 27/01/2019 14:12:33:
Tabel Eigenschappen-artikelen
- IDeigenschap
- IDartikel


En ik neem aan dan nog een tabel Artikelen_Eigenschappen_Waarden (of zoiets)
- IDartikel
- IDeigenschap
- Waarde

Die laatste, wordt dat dan een "(var)char"? Daar kan wel alles in, maar voor integers natuurlijk niet ideaal. Zeker als je wilt zoeken op 10 < x < 100, dat gaat alfabetisch niet echt goed ...

Bart Smulders op 27/01/2019 14:19:48:
Dit gaat voor meer dan 50000 artikelen toch een elle lange lijst geven?


Daar heb je nou een database voor, die doet daar niet moeilijk over ;-) In de lengte of in de breedte, het blijft dezelfde hoeveelheid data. Het gaat erom hoe makkelijk je er mee kan "goochelen", en in de lengte kun je veel makkelijker (lees: dynamischer) uitbreiden.
 
- Ariën -
Beheerder

- Ariën -

27/01/2019 14:41:01
Quote Anchor link
AL heb je 10.000.000 eigenschappen, dan is het alsnog peanuts voor een computer.
Als je een index in je database maakt, dan wordt het helemaal makkelijker zoeken voor hem ;-)
Gewijzigd op 27/01/2019 14:41:19 door - Ariën -
 
Rob Doemaarwat

Rob Doemaarwat

27/01/2019 15:05:07
Quote Anchor link
Die opmerking van mij over de "Waarde" kolom was overigens bedoeld voor een "bredere" discussie (lees: ik kaap het topic een beetje):
Rob Doemaarwat op 27/01/2019 14:27:57:
Die laatste, wordt dat dan een "(var)char"? Daar kan wel alles in, maar voor integers natuurlijk niet ideaal. Zeker als je wilt zoeken op 10 < x < 100, dat gaat alfabetisch niet echt goed ...

Iemand hier een beter oplossing voor? Denk bijvoorbeeld ook aan float getallen. Hoe sla je die op ("5", "5.0" en "5.00" zijn allemaal gelijk, maar niet als je als string vergelijkt)? Misschien een extra "numerieke" kolom (numerieke waarde zowel als string als in deze kolom opslaan, en dan bij zoeken op een numerieke waarde deze kolom gebruiken)? Of ... ?
 
Thomas van den Heuvel

Thomas van den Heuvel

27/01/2019 15:21:57
Quote Anchor link
Mja, maar het risico daar is dat je al snel een soort van database in een database aan het bouwen bent. Als je dat punt bereikt zou je je ook af kunnen gaan vragen om een andere strategie te hanteren.

Long story short: voor dynamische eigenschappen die een entiteit mogelijk wel of niet heeft: koppeltabellen, voor vaste eigenschappen die elke entiteit heeft: gewoon opnemen in de tabel.
 
Bart Smulders

Bart Smulders

27/01/2019 18:56:48
Quote Anchor link
@Arien
Dan zal ik inderdaad de verticale weg nemen.

Uit de comfortzone maar de juiste weg.

Bedankt voor de input!

EOF
 



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.