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
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.
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
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
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).
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.
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 ;-)
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 ... ?
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.
In navolging van jullie raad heb ik reeds de volgende structuur maar loop ik wederom vast.
Tabel Artikelen:
- ArtikelID (PK, Auto Increm.)
- Naam
- etc...
Tabel Artikelen_Eigenschappen
- A_EigenschapID (PK, Auto increm)
- ArtikelId
Tabel Algemeen_eigenschappen
- EigenschapId
- EigenschapTabel
- Beschrijving_NL
Met de volgende query haal ik de gecombineerde gegevens voor een artikel op:
<?php
SELECT Algemeen_eigenschappen.EigenschapId,Algemeen_eigenschappen.EigenschapTabel,Algemeen_eigenschappen.Beschrijving_NL,Artikelen_eigenschappen.ArtikelId,Artikelen_eigenschappen.Eigenschapwaarde
FROM
Algemeen_eigenschappen
INNER JOIN
Artikelen_eigenschappen
ON
Artikelen_eigenschappen.A_EigenschapId=Algemeen_eigenschappen.EigenschapId;
?>
Met als resultaat:
EigenschapId EigenschapTabel Beschrijving_NL ArtikelId Eigenschapwaarde
1 Eigenschap_Vorm Vorm 1 1
2 Eigenschap_Voltage Voltage 1 2
Dan per EigenschapTabel een nieuwe Query uit te voeren om de eigenschappen op te halen of kan ik op een eenvoudige manier de resterende gegevens ophalen om het overzicht te bewaren?
Daar een eigenschap voltage niet alleen bestaat uit enkel bv 230V AC <- opgesplitst in 230, V, AC .
Uit de data haal ik bv
SELECT *
FROM
Eigenschap_Voltage
WHERE
EvoltageId = 2
Als response krijg ik dan 24 V AC
Tabel Eigenschap_Voltage
- EvoltageId
- Voltage
- Stroomtype
- SpanningDuiding
Mijn vraag is dus 2 ledig.
1= Kan ik met deze database structuur verder?
2= Hoe kan ik vanuit het resultaat van Query 1 ook query2 generen in 1x ?
Idealiter wil je dit in zo min mogelijk tabellen onderbrengen, zodat dit ook zo min mogelijk queries kost.
Het klinkt, als ik naar het oorspronkelijke vraagstuk kijk, dat je de eigenschappen ook wilt onderbrengen in rubrieken.
Wat ik dan zou verwachten is dat je ook een eigenschap type (of -categorie) hebt, naast een eigenschap waarde. Voor deze typen zou je ook een aparte tabel aan kunnen maken en deze typen zouden ook hiërarchisch ingedeeld kunnen worden, maar dat is mogelijk extra voor later.
Zoals in het bovenstaande bericht zou je dus geen aparte kolommen moeten aanmaken voor deze typen en waarden, want dan wordt het een complete nachtmerrie om hier generiek informatie in op te zoeken. Wat je waarschijnlijk beter zou kunnen doen is zoiets:
id: 1
type: spanningssoort
waarde: gelijkstroom (DC)
Oftewel je slaat de hele structuur op deze manier plat. Benodigdheden zijn in beginsel een eigenschapwaarde-tabel en een eigenschaptype-tabel. Vervolgens een koppeltabel om deze eigenschapwaarden te koppelen aan het ding waar ze betrekking op hebben.
Ook is het een beetje raar dat je dit soort dingen aan artikelen wilt koppelen, tenzij het artikel gaat over elektronische apparaten? Die hebben eigenschappen. Artikelen kunnen gaan over diverse zaken, dus de koppeling daar zou ook wat losser moeten. Vaak wordt dit gedaan door middel van tags, maar dit zijn enkel tekstveldjes, en verder niets. De vermelding van het model en type van het apparaat is interessant voor een artikel, het specifieke voltage (als artikeleigenschap) gaat misschien wat ver...
Als het artikel bijvoorbeeld gaat over een telefoon heb je bijvoorbeelde de tags "mobiele telefonie", "Samsung" en "Galaxy S10" ofzo. Dit stelt je in staat om heel snel in te zoomen op artikelen met specifieke informatie. Maar dit is iets anders dan een precieze specificatie van een apparaat.
