Hoofdplaatje ook in producttabel opslaan of niet?

[Verwijderd]

Ik heb een database vraagje. Stel, je hebt een tabel genaamd Product en een tabel Productfoto. In de tabel Productfoto (die gekoppeld is aan tabel Product) kan per product een onbeperkt aantal afbeeldingen worden opgeslagen. Omwille van de makkelijkheid zou je in de tabel Product ook 2 velden voor een hoofdafbeelding (zoals Hoofdplaatje en Hoofdplaatje_klein) kunnen gebruiken. Zo hoef je bij een query voor het overzicht van alle producten met daarin alleen de hoofdafbeelding geen andere tabel te raadplegen zoals de tabel Productfoto. Dus bij een query van het overzicht zal de query wat sneller zijn. OpenCart werkt volgens mij op die manier. En Wordpress misschien ook, met de uitgelichte afbeelding. Nadeel is dat je wat dubbele code hebt, om ook in de tabel Product een verwijzing van een afbeelding en thumb op te nemen.

Wat zouden jullie doen? Alle (verwijzingen naar) de plaatjes in de tabel Productfoto houden, of in de tabel Product ook 2 veldjes neerzetten voor het hoofdplaatje?

[Onbekend]

De data niet redundant opslaan in de database. Gewoon dus in de tabel Product de key opslaan waar de hoofdfoto en thumb gevonden kan worden.

Ander vraagje: Waarom sla je afbeeldingen op in de database en niet als losse foto in een map? In de database hoef je alleen maar het relatieve pad naar de foto dan op te slaan.

[Verwijderd]

Okee. Zoals het nu is, sla ik juist in de tabel Productfoto de id op van het product uit de tabel Product. Dat is net andersom met wat jij zegt. Maar misschien bedoelen we hetzelfde?

De afbeeldingen staan in een losse map hoor. Alleen de namen van de afbeeldingen staan in de database.

// edit: Ik zat nog te denken. Soms heeft een klant een platte database. Dan staat de verwijzing van het plaatje ook in dezelfde tabel. Bij 2 klanten is dat zeker het geval, omdat hun kassa-software alles plat opslaat in de database. Elke variatie is dan ook een los record, op zich goed, want ook elk EAN is anders. Maar voor maten en kleuren is het soms minder handig. Anyway, als je exporteert en weer importeert zou het in die gevallen wel handig zijn als er ook in de normale producttabel nog wel plek is voor 1 hoofdplaatje. Aan de andere kant is dat ook wel op te lossen door de importfunctie wat te herschrijven dat het plaatje in een losse tabel Productfoto komt.

[ Voor 75% gewijzigd door Verwijderd op 28-01-2018 17:42 ]

[P_Tingen]

Redundantie is geen enkel probleem, zolang het binnen de perken blijft. Als queries traag zijn en je kan het oplossen door een redundant veld in de hoofdtabel op te nemen, dan vooral doen.

Maarrrrrr.

Vaak wordt er veel te snel vanuit gegaan dat er wel een performanceprobleem zal zijn. Redundantie is een vorm van optimalisatie en hier zou ik willen adviseren om de werkwijze van Michael A. Jackson te hanteren:

We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.

Dus probeer het eerst eens netjes te doen. Is het te traag, dan neem je de hoofdafbeelding op in de producttabel.

[Verwijderd]

Okee @P_Tingen en @Onbekend, ik was inmiddels al bezig het los en netjes te doen.
Daarna kunnen we eventueel altijd nog zien inderdaad. Maar ik denk eigenlijk dat dat niet nodig zal zijn.
Dat is een mooie werkwijze van Michael A. Jackson trouwens.

[ Voor 44% gewijzigd door Verwijderd op 29-01-2018 12:09 ]

[emnich]

Je kan er ook nog voor kiezen om de hoofdafbeelding zo op te slaan dat je deze met een herkenbare URL kan ophalen.

Dus bijv: https://site.nl/products/[product_id].jpg

Dan hoef je helemaal geen (aparte) query te doen voor de hoofdafbeelding omdat je die URL zelf kan samenstellen.

[MatHack]

Verwijderd schreef op zondag 28 januari 2018 @ 17:02:
Okee. Zoals het nu is, sla ik juist in de tabel Productfoto de id op van het product uit de tabel Product. Dat is net andersom met wat jij zegt. Maar misschien bedoelen we hetzelfde?

Als ik de opmerking van @Onbekend goed lees bedoelt hij dat je het id van de Productfoto tabel waarin het hoofdplaatje staat als id in de Product tabel, zodat je vanuit de Product tabel kunt zien welk record uit de Productfoto tabel het hoofdplaatje is. Je wil nog steeds de Productid in de Productfoto tabel hebben staan.

[Verwijderd]

@emnich Ha, dat is een goede tip. Er zijn in mijn geval wel meerdere plaatjes per product mogelijk, en de volgorde daarvan kan ook aangepast worden. Dus het hoofdplaatje kan op die manier wel wisselen. Op dit moment sla ik ze op met als naam uniqid() .jpg/.gif/.png, dus dan kan je ze ook niet zomaar raden als iemand wat in de adresbalk intypt.

@MatHack
"... bedoelt hij dat je het id van de Productfoto tabel waarin het hoofdplaatje staat als id in de Product tabel, zodat je vanuit de Product tabel kunt zien welk record uit de Productfoto tabel het hoofdplaatje is".
=> Ja, zo las ik het ook.
"Je wil nog steeds de Productid in de Productfoto tabel hebben staan."
=> Okee, dan staat het hoofdplaatje er dus 'dubbel' in, zeg maar. Want in elk Productfoto record staat al elke foreign key naar het product_id uit de tabel Product. Maar in de tabel Product staat dan dus ook 1 veld met daarin de verwijzing naar het productinfo_id oftewel naar het hoofdplaatje in tabel Productfoto.

Wat ik in mijn geval nu doe is in de lijst met resultaten van de tabel Product (SELECT * FROM Product) per resultaat nog een query voor het plaatje (SELECT plaatje FROM Producfoto WHERE product_idfk = $row['product_id '] ORDER BY plaatjevolgorde LIMIT 0, 1). Dit is wat versimpeld hoor. Die Limit heb ik erin gezet zodat hij niet naar de rest van de plaatjes kijkt, dat zal wel iets schelen. Ik kan deze 2 queries natuurlijk ook combineren met JOIN (of gewoon WHERE) en dan zal ik ook die Limit erin laten staan.