De PHPhulp kroeg
Producten koppelen (welke werkwijze)
Om de producten te koppelen wil
Ik gebruik maken van de productID
Momenteel heb ik het nu werkend om de productID te verkrijgen van de artikelen die ik wil koppelen
Nu moet ik alleen nog de kenmerken van de variatie hieraan toevoegen bijvoorbeeld kleur of materiaal etc.
Nu zou ik graag wat input willen hebben wat jullie zouden doen qua opslaan (array vorm? Of andere manier)
Hoe je de DB hiervoor zou inrichten. (relative tables?)
Gewijzigd op 18/11/2020 22:38:39 door Thomas van den Heuvel
Elke productvariant, dus elk ProductModel, moet dan inderdaad een unieke product-ID hebben, anders kun je de varianten niet uit elkaar houden.
Met een EAV-infrastructuur (in het gelinkte topic) heeft dat verder weinig te maken. EAV (entity-attribute-value) is slechts een databasetechniek om productdata op te slaan in een relationele database, maar dat bepaalt niet hoe je productmodellen ontwerpt.
Een andere aanpak kan zijn om een tabel aan te maken met basiseigenschappen die alle producten met elkaar gemeen hebben, zoals naam, SKU, etc. Met daarnaast per productsoort een tabel waarin unieke eigenschappen in kunnen worden opgeslagen.
De eigenschappentabel kan je koppelen aan de basistabel door te werken met dezelfde primaire ID's.
Je kunt het zo maken dat de PRIMARY KEY in de hoofdtabel een AUTO_INCREMENT heeft, en daarnaar verwijzen vanuit de eigenschappentabellen met een PRIMARY KEY die tevens een FOREIGN KEY constraint heeft naar de PRIMARY KEY van de hoofdtabel.
Wil je meer met AUTO_INCREMENT doen, dan is het handig als je database SEQUENCES ondersteunt. MySQL doet dat bij mijn weten nog steeds niet, zelfs niet in de huidige versie 8.0. Maar MariaDB en PostgreSQL doen dat wel:
MariaDB: https://mariadb.com/kb/en/create-sequence/
PostgreSQL: https://www.postgresql.org/docs/current/sql-createsequence.html
Ja, het kost wel meer werk om op te zetten, maar dan heb je de voordelen van SQL zoals garanties op data-integriteit en -kwaliteit. Dat is meestal de hoofdreden om iets in SQL te willen doen.
In sommige gevallen wil je liever iets EAV-gerelateerds doen, en hoeft de nadruk niet op SQL te liggen.
In zulke gevallen kan je ook besluiten om met JSON-strings te werken, en deze op te slaan in een JSON-kolom.
PostgreSQL: https://www.postgresql.org/docs/10/datatype-json.html
- https://www.postgresql.org/docs/current/functions-json.html
MariaDB: https://mariadb.com/kb/en/json-functions/
MySQL: https://dev.mysql.com/doc/refman/5.7/en/json.html
Dan kan je in SQL-queries werken met handige JSON-functies van de database.
Quote:
Met een EAV-infrastructuur (in het gelinkte topic) heeft dat verder weinig te maken. EAV (entity-attribute-value) is slechts een databasetechniek om productdata op te slaan in een relationele database, maar dat bepaalt niet hoe je productmodellen ontwerpt.
Als je met productmodellen code bedoelt, die bepaalt hoe je verder met deze (database-)data werkt, dan ja, dat staat dan redelijk los van elkaar, maar dit sluit elkaar ook niet uit? Vormt een EAV database-aanpak een belemmering?
Quote:
Je wilt het EAV-model vermijden, omdat het weinig met SQL te maken heeft.
Als je met EAV-model een soort van "database-in-een-database"-aanpak bedoelt dan ja, dit kun je beter vermijden omdat dit voor een aantal issues zorgt (o.a. fragmentatie van data). Behalve wellicht als dit een redelijk efficiënte oplossing vormt voor een zekere mate van gewenste flexibiliteit. Magento gebruikt volgens mij nog steeds een EAV-aanpak, dat zegt toch ook wel wat.
En voordat dit (weer?) ontaardt in gebakkelei over de vorm van een oplossing lijkt het mij misschien handig om het doel niet uit het oog te verliezen.
Wat voor aanpak je ook kiest, op een gegeven moment moet je de data die je in je database gestampt hebt er ook weer op een efficiënte en makkelijke manier uit kunnen trekken en hiermee makkelijk kunnen zoeken (denk aan facetted searches etc.). Hoe je dit optimaliseert wordt (mede) bepaald door hoe je deze data gebruikt. Het ontwerp van je database zou dit doel moeten dienen en aan moeten sluiten bij het gebruik.
Ik zou haast zeggen dat het irrelevant is welke vorm dit precies aanneemt zolang het doel maar wordt bereikt.
Thomas van den Heuvel op 20/11/2020 16:07:07:
En voordat dit (weer?) ontaardt in gebakkelei over de vorm van een oplossing lijkt het mij misschien handig om het doel niet uit het oog te verliezen.
Inderdaad, maar welk doel? Eenvoudig zoeken? Is dat wat Ben bedoelt met "Hoe je de DB hiervoor zou inrichten."?
Ik haal dat er niet uit. Volgens mij vraagt hij juist naar normalisatie in de eerste alinea.
Voor snel en eenvoudig zoeken met mijn eerdere suggestie kan je complexere structuren vereenvoudigen met VIEWs, en queries versnellen met indices, zoals gebruikelijk met SQL.