Database structuur voor artikel eigenschappen
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.
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 -
- 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.
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?
- 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
- 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.
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 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 ... ?
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.
Dan zal ik inderdaad de verticale weg nemen.
Uit de comfortzone maar de juiste weg.
Bedankt voor de input!
EOF
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:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?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;
?>
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 ?
Alvast bedankt.
Gewijzigd op 21/05/2019 22:31:27 door Bart Smulders
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)
id: 2
type: spanningssoort
waarde: wisselstroom (AC)
et cetera.
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.
Gewijzigd op 22/05/2019 11:37:21 door Thomas van den Heuvel
Thomas van den Heuvel op 22/05/2019 11:28:38:
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)
id: 2
type: spanningssoort
waarde: wisselstroom (AC)
et cetera.
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.
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)
id: 2
type: spanningssoort
waarde: wisselstroom (AC)
et cetera.
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.
Thomas,
Dank voor jou antwoord.
Ik tracht hier zoveel als mogelijk normalisatie toe te passen en uiteraard zijn er hier mensen die dit overkill vinden. En het klopt dat de waarden zoals V of mV zullen gebruikt worden voor specifieke artikelen.
Op de manier die je beschrijft waarbij de waarde en eigenschap in 1 tabel tezamen komen heb je natuurlijk een Varchar in gebruik aangezien niet alle waarden alleen cijfers of alleen letters zullen bevatten.
Echter stel ik mij dan de vraag wanneer men spreekt over het gebruik van Taal voorkeur men soms zal vinden dat wanneer een artikel als vorm eigenschap bv "vierkant" heeft dit niet in hun taal word weergegeven.Met nog een kolom Waarde_NL, Waarde_FR, Waarde_DE is dat ook opgelost .
Toevoeging op 26/05/2019 13:18:07:
Adoptive Solution op 22/05/2019 08:15:46:
Adoptive,
Het artikel gelezen en gezien dat het niet de meest ideale manier is van mij om dan tabellen als waarde op te geven.
Desalniettemin is mijn vraag wel beantwoord.
Waarvoor dank.
Quote:
En het klopt dat de waarden zoals V of mV zullen gebruikt worden voor specifieke artikelen.
Dat kun je dan in "type" voltage onderbrengen en "waarde" XXX V of YYY mV, en als je dit nog verder wilt uitsplitsen kun je daarvoor "type" voltage_eenheid gebruiken, met mogelijke "waarden" v, mV et cetera. Tis maar net hoe fijnkorrelig je de informatie wilt presenteren.
Maar dit lijkt mij nog steeds de spec van een apparaat, en niet zozeer eigenschappen van een artikel ;).
Om de gedachtegang te doorbreken stel ik toch voor om het pad van de "deallocate" op te gaan om aldus danig de bijhorende tabel per artikel op te vragen met daarin de gecombineerde specificaties per artikel.
Mijn brein is niet in de mogelijkheid om abstract genoeg te kunnen denken om dit probleem op te lossen.
Er bestaat echter zo weinig info op het eerste zicht over hoe eigenschappen of specificaties worden opgeslagen in een database wat dit betreft. Ik kan niet verder met input van gegevens zonder dit eerst in orde te brengen.
En wat versta je precies onder een "artikel"? Is dit een tekst met een specifiek onderwerp (denk aan een nieuwsitem of blog), of is dit meer een productpagina? Misschien praten we langs elkaar heen. Wat is de precieze toepassing van deze pagina's / de website? Is dit voor publiek gebruik of meer voor intern gebruik (intranet?) om een soort van digitaal archief aan te leggen?
Een artikel voor mij is bv een motor met als artikel nr 1234
Een motor heeft eigenschappen zoals bv
Toerental
Vermogen
Voltage
enz..
Door op deze manier te werken kan je zelfs wanneer een nieuw artikel werd aangemaakt een set maken die werkbaar is.
Compatibiliteit controle of oud vs nieuw vergelijk enz.
Ik was nu meer aan het denken om alle eigenschap tabellen met hun unieke waarden een join te maken zodat deze in een tabel zitten die wederom kan gebruikt worden om de gegevens per artikel weer te geven met php in een foreach.
Doordat je een tabel met alle eigenschappen hebt en hun tabelnaam maak je de join
EigenschapId EigenschapTabel Beschrijving_NL Beschrijving_FR
1 Eigenschap_Vorm Vorm Forme
2 Eigenschap_Voltage Voltage Tension
Vervolgens maak je de join met de waarden die je verkrijgt uit de eigenschapTabel
Die join zal dan alle eigenschappen bundelen.
Vervolgens trek je de artikelen die je nodig hebt erbij in je join en klaar.
-- hoop ik toch--
Tenzij er nu een andere oplossing naar boven komt. :)
De website zal niet publiek gebruikt worden . En eveneens een digitaal archief.