Database structuur voor artikel eigenschappen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Als PHP programmeur werken aan IT oplossingen voor

Vacature Omschrijving Deze fraaie partij ondersteunt bedrijven bij hun technische vraagstukken door middel van software, trainingen, de inzet van specialisten en state of the art apparatuur. Hun missie is: “Het leveren van technische producten, diensten en systemen die van meerwaarde zijn voor de opdrachtgevers.” Zij beantwoorden dan ook de meest uiteenlopende technische vraagstukken, waarbij zij zich richten op vijf marktsegmenten: Bovengrondse Infrastructuur, Ondergrondse Infrastructuur, Bouw & Installatietechniek, Geo & Data en Industrie & Energie. Als technisch specialist ontwerpen zij niet alleen producten en oplossingen voor deze marktsegmenten, maar nemen zij ook het beheer en onderhoud op zich. Deze groeiende partij

Bekijk vacature »

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

25/08/2019 21:22:43
 
- 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
 
Bart Smulders

Bart Smulders

21/05/2019 22:29:24
Quote Anchor link
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:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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;
?>


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
 
Adoptive Solution

Adoptive Solution

22/05/2019 08:15:46
 
Thomas van den Heuvel

Thomas van den Heuvel

22/05/2019 11:28:38
Quote Anchor link
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.
Gewijzigd op 22/05/2019 11:37:21 door Thomas van den Heuvel
 
Bart Smulders

Bart Smulders

26/05/2019 13:15:33
Quote Anchor link
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.


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,

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

26/05/2019 16:34:53
Quote Anchor link
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 ;).
 
Bart Smulders

Bart Smulders

26/05/2019 19:12:46
Quote Anchor link
@Thomas,

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

26/05/2019 21:55:12
Quote Anchor link
Hm. Laten we het eens omdraaien. Wat wil je uiteindelijk bereiken met het toevoegen van dit soort "metadata" aan artikelen, of wat wil je uiteindelijk met deze informatie doen - waarom heb je deze nodig?

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?
 
Bart Smulders

Bart Smulders

27/05/2019 21:11:42
Quote Anchor link
Deze data heb ik nodig om in een latere fase met de gegevens set te werken in een configurator.
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.
 



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.