Dynamisch webshop design

[4Real]

Er is mij gevraagd om een webshop op te zetten en toen ik over nadacht groeide de lijst van mogelijke functionaliteiten al snel in het oneindig. Daarnaast heb je genoeg off-the-shelf producten, dus daar maken ze nu gebruik van. Echter tijdens het nadenken bleef ik vastzitten op het volgende: "hoe sla je producten in de database op?.

Het begint uiteraard simpel. Een product heeft een naam, omschrijving en prijs. Iedereen kan deze tabel wel dromen, maar een Intel processor kan een i5 of i7 core hebben. Ik kan geen core kolom opnemen, want daar heeft een fietsenwinkel niets aan. Dus, er moet een generiek ontwerp komen.
Enige tijd later kwam het volgende eruit:


Zo kan een computer winkel een core type als attribuut opnemen en een fietsenwinkel een bandgrootte of fiets kleur opnemen. Alle waardes worden in de koppeltabel opgeslagen.
Hiermee kun je veel meer mogelijkheden van producten aanbieden en relatief eenvoudig op deze waardes zoeken, maar hier zit ook direct een probleem. Core type en kleur kunnen in een string worden opgeslagen, maar bandgrootte kan best in een integer. In dit ontwerp is het niet mogelijk om de BETWEEN functie te gebruiken.

Ontwerp 2:


Zelfde als hierboven kwa mogelijkheden, maar nu heeft de koppeltabel verschillende kolommen gekregen voor de verschillende datatypes.
Ik vind het niet echt een prachtige oplossing, maar het biedt wel weer meer mogelijkheden. Andere oplossingen die ik ook nog heb gezien is: per datatype een waarde tabel. Dit vind ik een Join nachtmerrie, dus dat is niet.

Over joins gesproken. Wanneer ik nu een product wil ophalen moet ik querien over drie tabellen. Het mooiste zijn als je een heel product met één select er uit kan trekken, zonder joins. Een idee is nog om het product in zijn geheel als JSON string op te slaan binnen de product tabel. Zo hoef je alleen joins te te passen in de zoekmachine.

Waarom geen tabel per product? 'Fysiek' wordt er een database tabel aangemaakt welke zo wordt gemodellerd zoals de gebruiker aangeeft. Voordeel is dat de tabel precies aansluit bij de wensen van de gebruiker. Nadeel is dat het systeem nooit kan weten welke tabel hij moet benaderen, dus je zal metadata moeten opslaan. Daarnaast is zoeken over kleding welke rood ook praktisch onmogelijk. Of je moet lelijke union queries gaan schrijven.

Metadata ontkom je dus niet aan, maar een hybride vorm van database tabel per product en metadata tabellen vond ik opzich wel een leuke oplossing. De data wordt dan wel dubbel opgeslagen, maar ruimte is niet echt het grootste probleem tegenwoordig.

Echter nu heb ik alleen nog maar naar attributen gekeken, als je product varianten gaat opnemen dan wordt het een ander spel. Bijvoorbeeld: http://stackoverflow.com/...ariants/24941744#24941744
Aantal tabellen en een aantal relaties. Ik vind het een mooi ontwerp wat je veel ruimte geeft, echter de joins....
Daarnaast is hier ook weer sprake van het data type probleem dat eerder is beschreven.

Conclusie: er moeten keuzes worden gemaakt.
Persoonlijk vond ik de hybride optie tussen een generiek datamodel en product tabellen wel een leuke oplossing. Meer omdat het systeem zelf alles dan aan zal maken en inregelt. Tevens tijdens het zoeken op product attributen heb je het voordeel dat je alleen naar dat product kijkt en dan de voordelen van een datatabel kan gebruiken. Kwa snelheid zie ik hier voordelen. Zoals eerder aangegeven zoeken naar meerdere producten zie ik weer nadelen, maar daar kan het generieke model hulp bieden.

Ik ben wel benieuwd naar wat jullie denken en andere gedachten. Geheid dat ik datamodel patronen niet ken en misschien wel mogelijkheden bieden. Het is in ieder geval een leuk gedachtenpuzzel om in de file over na te denken

[Ramon]

Twee dingen

1) Als joins een probleem zijn dan moet je een andere ORM gebruiken ofzo. Joins zijn de normaalste zaak van de wereld en zou je niet moeten vermijden.

2) Voor het filteren in een zoek-overzicht, zoals in je voorbeeld van bandmaten, gebruik je natuurlijk een zoekmachine die faceting ondersteunt.

[Laurens-R]

1. Joins zijn niet eng. Een goede relationele db engine optimaliseert die als een malle.

2. Klinkt als een probleem wat velen voor jou al opgelost hebben. Ik zou zeggen; zoek het internet af op voorbeelden. En kijk idd niet alleen sec naar database design en queries... Er is ook tooling beschikbaar voor het doen van searches, het exposen van json interfaces etc. Probeer vooral niet alles zelf uit te vinden; doe jezelf een lol.

3. Maak design technisch een afweging hoe dynamisch, dynamisch is. Je kan van alles een attribuut maken, maar zaken als prijzen, namen, productomschrijvingen, fabrikanten heb je altijd wel... Maak van dat soort algemene delers gewoon een kolom, dan kan je ook gerichter/optimaler queries uitvoeren. Again: maak het jezelf niet te moeilijk.

4. Weeg alles af tegen je requirements. Het is niet erg om een lichte architectuur consessie te doen als dat ontwikkeling gemakkelijker maakt. Er zijn goede reden te bedenken waarom je bijvoorbeeld voor zowel numerical attributes en text attributes zou gaan ipv van 1 generiek attribute tabel, als daar een goede requirement tegenover staat.

5. Is een attribuut een attribuut? Heeft een velg een 19" maat (attribuut) of verkopen we gewoon een 19" velg (product)

[ Voor 50% gewijzigd door Laurens-R op 16-12-2015 00:27 ]

[Gomez12]

Vraagje, wil je een wegschop voor de maakindustrie maken of voor de handel?

Want in de maakindustrie kan het nog weleens gebeuren dat een attribuut irrelevant is (omdat ze bijv blauwe en groene verf hebben, welke ze gebruiken is niet zo relevant).
Maar in de handel heb je bijna altijd onder producten nog een artikelen zitten en dat is hetgeen wat je verkoopt, een artikel heeft ook geen keuze in attributen meer, die zitten gewoon vast in het artikel, enige mogelijkheid die je nog hebt is dat een product een samengesteld artikel is (bijv een computer op maat gemaakt)

Ik zou zeggen dat een i5 of i7 of voor mijn part een fietsband diameter absoluut geen attribuut is, maar gewoon losse artikelen.
Jouw computerwinkel moet namelijk gewoon weten hoeveel i5's of i7's er in de voorraad liggen op elk moment, ze moeten ook los besteld worden dus voor je totale administratie wil je het ook verkopen met een artikelnr.
Zelfde met je fietsenmaker, die moet die velgen gewoon inkopen met een bepaalde maat, die kan je normaliter ook gewoon kopen als je zelf handig bent en hem erin kan zetten oftewel dat heeft een artikelnr want een attribuut kan je niet los verkopen.

En qua joins etc. Dat is meer een kwestie van grootte, wat is je verwachte grootte van je shop, is dat niveau amazon of bol.com of de computerwinkel op de hoek?
Want bij echt grote shops is het niet ongebruikelijk om gewoon een gescheiden backend (genormaliseerd rdbms) en een gescheiden frontend (kan een nosql zijn, maar kan ook een gedemoraliseerd rdbms zijn) te hebben.
Want bij de invoer van artikelen en de mutaties van artikelen wil je juist "zoveel mogelijk" joins hebben, dat voorkomt dubbele waardes met risico op foutieve invoer etc.
En je frontend ontvangt dan enkel het resultaat van je genormaliseerde data om te tonen.
En zoeken doe je via een zoekmachine waar normaliter geen database bij betrokken is.