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.
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.
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 .
[size=xsmall]Toevoeging op 26/05/2019 13:18:07:[/size]
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.
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?
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.
