Producteigenschappen in een database

[SH4D3H]

Hoe zouden jullie producteigenschappen opslaan in een database?

1) Je zou een producttabel kunnen maken met velden voor elke eigenschap.
Dat zou er bijvoorbeeld zo uit zien:
tabel producten
id :: naam :: lengte :: breedte :: kleur

Voorbeelddata:
1 :: kleine rode doos :: 100 :: 75 :: rood
2 :: kleine blauwe doos :: 100 :: 75 :: blauw
3 :: kleine groene doos :: 100 :: 75 :: groen
4 :: normale rode doos :: 150 :: 125 :: rood
5 + 6 blauw + groen
7 :: grote rode doos :: 200 :: 175 :: rood
8 + 9 blauw + groen

Dit levert nogal veel dubbele data op, tijd voor een nieuwe tabel?

2) Je zou een eigenschappentabel (+koppeltabel) erbij kunnen maken.
Bijvoorbeeld:
tabel producten wordt id :: naam
1 :: kleine rode doos
2 - 9 zie boven

tabel eigenschappen
id :: eigenschap :: waarde
1 :: lengte :: 100
2 :: lengte :: 150
3 :: lengte :: 200
4 :: kleur :: rood
etc.

tabel producteigenschappen
productid :: eigenschap id
1 :: 1
1 :: 4
1 :: 7 => kleine rode doos

Deze oplossing lijkt me de beste, hoewel ik nog altijd een hoop dezelfde data heb. Voor elke waarde moet ik namelijk aangeven of het een lengte of breedte betreft. Zoals je in het voorbeeld ziet zijn die niet altijd uitwisselbaar. Je kunt bijvoorbeeld geen doos met breedte 100 krijgen.

De echte database heeft nog veel meer verschillende (en dezelfde) eigenschappen per product.

Ik vroeg me af of ik hier nog wat aan kon doen of dat ik nu gewoon doorgeslagen ben

[Jan_V]

Ik zou het denk ik op deze manier verder uitsplitsen.
Een tabel voor de producten en een tabel voor de maten welke dmv een FK zijn gekoppeld.

ID	Omschrijving	TypeID	Kleur
1	Kleine rode doos	1	Rood
2	Kleine blauwe doos	1	Blauw

TypeID	Lengte	Breedte
1	100	75
2	150	125

Wellicht zou je de kleuren nog in een andere tabel kunnen stoppen, maar in dit voorbeeld zie ik daar geen aanleiding voor.
Zo'n extra koppel tabel zou ik afraden in dit geval, aangezien het alleen maar complexiteit oplevert en niet echt toegevoegde waarde heeft. Dit koppel tabel heeft toch ook een n:n relatie als ik het zo bekijk? Dat wordt normaal sowieso al afgeraden dacht ik, tenzij je echt zeker weet dat het nuttig is.

[mithras]

Wij werken in onze e-commerce oplossing met product groepen en daarin unieke sales units. En productgroep heeft een naam (broek model X). Sales units verschillen op basis van maat en kleur bijvoorbeeld.

Je hebt een tabel met variates (productgroep A kent variatie i en j). Je hebt een tabel met sales unit (sales unit I kost x en sales unit II kost y). Tot slot een koppeling (sales unit I heeft bij variatie i de waarde p en bij variatie j de waarde q; sales unit II heeft bij variatie i de waarde r en bij variatie j de waarde s).

Samenvattend: vier tabellen: productgroepen, sales units, variaties en koppeltabel unit <> variatie. Dan ben je extreem flexibel in je opzet

[SH4D3H]

@Jan_V En als ik nu besluit dozen met verschillende diktes te gaan verkopen? Of dieptes? Sluitingen? Patronen?

Stel je dan het volgende voor:
id :: naam :: typeid :: kleur :: patroon
1 :: kleine, dunne, blauwe doos met witte stippen :: 1 :: blauw :: stippen
2 :: kleine, dikke, blauwe doos met witte strepen :: 3 :: blauw :: strepen

id :: lengte :: breedte :: dikte
1 :: 100 :: 75 :: 10
2 :: 100 :: 75 :: 15
3 :: 100 :: 75 :: 20

Het probleem is voornamelijk dat niet alle eigenschappen vooraf vastliggen. Uiteindelijk kan het om tuinstoelen gaan, maar ook om Windows 7 om maar wat te zeggen. Daarbij komt nog dat er ook producten zijn, bijvoorbeeld dozen, waarbij slechts 1 enkele eigenschap verschilt van de rest. Je hebt dan min of meer (een behoorlijk aantal) dubbel(e) record(s).

[kwaakvaak_v2]

Ik zou eerder eens kijken naar iets buiten het traditionele relationele database model, en eens kijken naar een product als couchDB of mongoDB.

Als je een product bekijkt als entiteit met verschillende eigenschappen, kun je die met een eigen definieerbare sleutel vast leggen als een key -> value paar en bloedsnel terug halen in je product.

En ja hoor, die noSQL systemen zijn erg nieuw en op dit moment behoorlijk in de hype, maar zeer zeker wel productie rijp!

[Creepy]

Allemaal leuk en aardig, maar onderbouw eens waarom je over zou stappen op couchDB o.i.d.? Want m.b.v. een "key" (lees: index) kan je ook prima en snel een product uit je "gewone" DB halen. Dus wat is het daadwerkelijke voordeel in dit geval dan? Je zult nu van te voren goed moeten nadenken over je key, en als je via een andere weg je data op wilt halen zul je het vaak dubbel moeten opslaan, wat een nadeel kan zijn.

[ Voor 30% gewijzigd door Creepy op 17-06-2010 22:51 ]

[RobIII]

Creepy schreef op donderdag 17 juni 2010 @ 22:49:
Allemaal leuk en aardig, maar onderbouw eens waarom je over zou stappen op couchDB o.i.d.? Want m.b.v. een "key" (lees: index) kan je ook prima en snel een product uit je "gewone" DB halen. Dus wat is het daadwerkelijke voordeel in dit geval dan?

Nou, in een NoSQL DB zul je veel makkelijker kunnen omgaan met verschillende producteigenschappen per product. Ga je dit, zoals "optie 2" zitten bouwen in een RDBMS dan zit je al gauw een DB-in-een-DB te bouwen en dat performed ook niet echt je-van-het. Los van het feit dat 't ellende is om fatsoenlijk te zoeken op bepaalde (waardes van) eigenschappen e.d.

Ik zeg niet dat "blind" kiezen voor een NoSQL (danwel RDBMS) slim is; je zult voor jezelf moeten uitzoeken wat 't kost aan ontwikkeltijd, leercurve, whatever en dan zien welke zich 't best loont.

[ Voor 12% gewijzigd door RobIII op 17-06-2010 22:57 ]

[Soultaker]

Ik vind de oplossing waar SH4D3H op uit kwam sowieso al beter dan de suggesties die daarna gedaan zijn waarbij "hoogte" en "breedte" weer gewoon kolommen in een tabel zijn. Dat is een weinig flexibele oplossing. Ik kan me niet voorstellen dat bijvoorbeeld de Tweakers.net Pricewatch op die manier geïmplementeerd is, want er zijn zóveel verschillende (soorten) producten dat je elke week je databasemodel kunt updaten. Dat is niet echt praktisch.

Persoonlijk zou ik waarschijnlijk kiezen voor de meest genormaliseerde variant waarbij eigenschappen, waarden en producten allemaal hun eigen tabel hebben:

Eigenschap

Id	Naam	Eenheid	Minimum	Maximum	...
1	Hoogte	cm	0	1000	...
2	Breedte	cm	0	1000	...
..	..	..	..	..	..

Product

Id	Naam	Beschrijving	...
1	Doos	Een kartonnen doos.	..
..	..	..	..

ProductEigenschap

ProductId	EigenschapId	Waarde
1	1	30
1	2	50
..	..	..

Deze aanpak heeft als nadeel dat je wel een rij per combinatie eigenschap/product moet opslaan, maar dat had het oorspronkelijke voorbeeld ook. Het voordeel is echter dat je alleen de waarden van eigenschappen opslaat per product (en niet informatie over de eigenschap zelf) dus de overhead daarvan is relatief beperkt. De informatie over mogelijke eigenschappen (bijvoorbeeld dat breedte in centimeters gemeten wordt) zit netjes in een aparte tabel.

Bijkomend nadeel is dat je de "Waarde" kolom niet in de database van het goede type kunt voorzien. Het wordt dan waarschijnlijk een TEXT of een BLOB kolom die je in de applicatiecode moet interpreteren (evt. aan de hand van een "Type" kolom in de "Eigenschap" tabel). Een andere manier om dat probleem te omzeilen is aparte kolommen maken voor aparte typen (IntWaarde, FloatWaarde, BoolWaarde, TextWaarde b.v.). Dat is vooral essentieel als je range queries op een efficiënte manier op de database wil uitvoeren (bijvoorbeeld alle producten selecteren met breedte >= 100 cm).

Tenslotte: zoals je ziet zou ik een aantal basiseigenschappen die elk product heeft (zoals naam en omschrijving, misschien) wél gewoon in de hoofdtabel opnemen, zodat je die snel kunt opvragen. Maar het moet dan echt gaan op hele essentiële eigenschappen die voor álle productgroepen gelden.

[ Voor 6% gewijzigd door Soultaker op 17-06-2010 23:01 ]

[Confusion]

SH4D3H schreef op donderdag 17 juni 2010 @ 20:08:
Dit levert nogal veel dubbele data op, tijd voor een nieuwe tabel?
[..]
Ik vroeg me af of ik hier nog wat aan kon doen of dat ik nu gewoon doorgeslagen ben

De vraag is of het een probleem is dat je veel dubbele data hebt. Dat is bijvoorbeeld het geval als je tabel daardoor enorme afmetingen aan gaat nemen (laten we zeggen > 1 GB) of als het doorvoeren van wijzigingen heel bewerkelijk wordt, omdat je dan bijvoorbeeld in 2675 rijen de breedte van een doos aan moet gaan passen. Zolang dat allebei niet aan de orde is, zou ik me er geen zorgen over maken. Een volledig genormaliseerde database is in theorie leuk, maar in de praktijk is het ook best fijn als 'select * from table where breedte = 100' je gewoon alle data levert die je nodig hebt. Daar moet je gewoon pragmatisch mee omgaan.

[messi]

Je kunt natuurlijk ook een combinatie van beide systemen gebruiken.

Het scenario van de topic starter klinkt als een goede kandidaat voor een NoSQL database / document store als MongoDB. Het grote voordeel is dat je met 1 query alle data direct voor handen hebt, dus geen Joins e.d. wat de snelheid (zeker met enorm veel eigenschappen voor een product) erg ten goede komt.

Ook het zoeken op eigenschappen is erg simpel te implementeren. Zeker in mongo met behulp van nested keys en array searches.

[Soultaker]

Confusion schreef op donderdag 17 juni 2010 @ 22:59:
De vraag is of het een probleem is dat je veel data hebt. [..]

Volstrekt mee oneens. Dat is helemaal niet de vraag. De vraag is hoe je je database zó kunt inrichten dat je er nu en in de toekomst al je data in kwijt kunt zonder steeds structurele wijzigingen door te hoeven voeren die mogelijk queries breken.

Het doel van normalisatie is niet (in de eerste plaats) om voor opslagruimte te optimaliseren, maar om een flexibele en onderhoudbare datastructuur te creëren. In sommige gevallen is een gedenormaliseerde structuur juist efficiënter, maar zelden is die beter onderhoudbaar.

Ik begrijp dat NoSQL databases de hype van het moment zijn (twee jaar geleden had je er niemand over gehoord) maar ik hoor bijhoorlijk weinig argumentatie waarom een gebrek aan structuur een voordeel zou zijn in dit geval. Het voordeel van een getypeerde relationele database is dat er een zekere structuur in de data afgedwongen wordt waardoor je bij het opvragen niet voor verrassingen komt te staan. Ik snap dat die structuur achterwege laten nu tijd scheelt, maar gaat dat niet ten koste van de robuustheid van het systeem?

[ Voor 27% gewijzigd door Soultaker op 17-06-2010 23:08 ]

[RobIII]

Soultaker schreef op donderdag 17 juni 2010 @ 22:59:
Bijkomend nadeel is dat je de "Waarde" kolom niet in de database van het goede type kunt voorzien. Het wordt dan waarschijnlijk een TEXT of een BLOB kolom die je in de applicatiecode moet interpreteren (evt. aan de hand van een "Type" kolom in de "Eigenschap" tabel).

Dat is meteen 1 van mijn grootste problemen met dit datamodel; het zuigt gewoon om te zoeken naar producten met een afmeting van 1m50 tot 2m00 en een stroomverbruik van <100watt (ik roep maar wat). Want alles is "text"/"blob"/whatever dus je cast je scheel (en dan maar hopen dat 't goed gaat).

Soultaker schreef op donderdag 17 juni 2010 @ 22:59:
Een andere manier om dat probleem te omzeilen is aparte kolommen maken voor aparte typen (IntWaarde, FloatWaarde, BoolWaarde, TextWaarde b.v.). Dat is vooral essentieel als je range queries op een efficiënte manier op de database wil uitvoeren (bijvoorbeeld alle producten selecteren met breedte >= 100 cm).

Ah; ik had verder moeten lezen

Soultaker schreef op donderdag 17 juni 2010 @ 22:59:
Tenslotte: zoals je ziet zou ik een aantal basiseigenschappen die elk product heeft (zoals naam en omschrijving, misschien) wél gewoon in de hoofdtabel opnemen, zodat je die snel kunt opvragen. Maar het moet dan echt gaan op hele essentiële eigenschappen die voor álle productgroepen gelden.

Juist. My idea. Of dus een (vaak minder performante) "NoSQL" oplossing die net wat flexibeler is. Dat is, als performance niet zo'n probleem is, vaak qua ontwikkeltijd wel verdomd handig. En kosten die je daar mee uitspaart steek je maar in extra ijzer

[messi]

RobIII schreef op donderdag 17 juni 2010 @ 23:06:

Juist. My idea. Of dus een (vaak minder performante) "NoSQL" oplossing die net wat flexibeler is. Dat is, als performance niet zo'n probleem is, vaak qua ontwikkeltijd wel verdomd handig. En kosten die je daar mee uitspaart steek je maar in extra ijzer

Minder performant valt ook wel mee, de meeste NoSQL oplossingen zijn in dit soort gevallen een stuk sneller dan de SQL tegenhangers, MongoDB wordt bijvoorbeeld regelmatig als cache gebruikt voor SQL servers. Ook is schaalbaarheid geen probleem met zulke document stores.

[Alain]

Never mind - F5.

[ Voor 96% gewijzigd door Alain op 17-06-2010 23:12 ]

[kwaakvaak_v2]

RobIII schreef op donderdag 17 juni 2010 @ 22:56:
[...]

Nou, in een NoSQL DB zul je veel makkelijker kunnen omgaan met verschillende producteigenschappen per product. Ga je dit, zoals "optie 2" zitten bouwen in een RDBMS dan zit je al gauw een DB-in-een-DB te bouwen en dat performed ook niet echt je-van-het. Los van het feit dat 't ellende is om fatsoenlijk te zoeken op bepaalde (waardes van) eigenschappen e.d.

Ik zeg niet dat "blind" kiezen voor een NoSQL (danwel RDBMS) slim is; je zult voor jezelf moeten uitzoeken wat 't kost aan ontwikkeltijd, leercurve, whatever en dan zien welke zich 't best loont.

Persoonlijk zou ik dan zelf eerder voor mongo dan voor couch kiezen, maar dat komt omdat ik als php ontwikkelaar de API voor mongo wat robuuster aan vind voelen dan de REST interface van couch. Maar dat is persoonlijk.

Maar waarom, zoals mensen hierboven ook al schrijven, het feit dat je geen aanpassingen aan je datamodel hoeft te doen als je een product een extra eigenschap erbij krijgt, je het product gewoon als volledig object zo mongo in kunt schieten, je zelf je ID kunt samen stellen, en als je wat meer meta informatie aan een een document je er nog steeds makkelijk (en bizar snel!!) een query op los kunt laten;

code:

find({'product.kleur' => 'blauw'});

Ja relaties zijn wat lastiger, maar er staat nergens dat je niet een combinatie van beide systemen mag gebruiken. Het is toch een kwestie van een schema bedenken, en van te voren bedenken waar je wat vast gaat leggen.

Een RDMS koppelen met een noSQL systeem gewoon op basis van een ID,wat kan er voor zorgen dat je de relatie dingen in een systeem kan doen wat daar erg goed in is. De relaties tussen de producten onderling, of de relaties tussen producten en klanten, facturen, orders etc.

(alhoewel die orders bij een groot systeem in een noSQL in combinatie met een map/reduce algoritme weer best interessant kan zijn om heel snel een lijst op te bouwen van alle producten die iemand gekocht heeft, heeft een lijst met alle mensen die hetzelde product hebben gekocht etc. etc.)

Erg interessante blogpost wat hier beetje op aansluit is : http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/

En ja natuurlijk is het geen kwestie van even installeren en klaar. Maar systemen als mongo en couch zijn juist erg goed in het opslaan van data waar je van te voren nooit alles kunt bedenken wat er in de toekomst opgeslagen gaat worden.

Het lijkt mij voor de TS zeker een onderzoek waard, dat is... als de TS buiten het platgelopen pad van een RDMS durft/kan en mag lopen

[Confusion]

Soultaker schreef op donderdag 17 juni 2010 @ 23:05:
Het doel van normalisatie is niet (in de eerste plaats) om voor opslagruimte te optimaliseren,

In die eerste zin mistte ik het woord 'dubbele': ik herhaalde het probleem dat SH4D3H zag.

maar om een flexibele en onderhoudbare datastructuur te creëren. In sommige gevallen is een gedenormaliseerde structuur juist efficiënter, maar zelden is die beter onderhoudbaar.

Dat zei ik toch ook in het tweede deel van mijn reactie? Mijn punt was meer: als je een kleine webshop met pakweg 100 producten bent, waarvan er misschien telkens 5 eigenschappen delen, dan is de normalisatieslag om pakweg de afmeting van de verpakking er uit te halen echt overkill.

[cariolive23]

Wanneer je een mix van RDBMS en NoSQL wilt gebruiken, kijk dan eens naar PostgreSQL met de module hstore die in de contrib staat. Even laden en klaar is kees, heb je het beste van beide werelden tot je beschikking.

http://www.postgresql.org/docs/8.4/interactive/hstore.html

Ps. Langzame databases worden vaak veroorzaakt door brakke applicaties, voor performance hoef je dus niet naar NoSQL te kijken maar eerst eens naar je eigen applicatie. 100 records ophalen met 100 queries of met 1 query? Het scheelt nogal in performance...

[kwaakvaak_v2]

cariolive23 schreef op vrijdag 18 juni 2010 @ 09:22:
Wanneer je een mix van RDBMS en NoSQL wilt gebruiken, kijk dan eens naar PostgreSQL met de module hstore die in de contrib staat. Even laden en klaar is kees, heb je het beste van beide werelden tot je beschikking.

http://www.postgresql.org/docs/8.4/interactive/hstore.html

Dat heb je niet tot je beschikking, je hebt een implementatie van het principe binnen een RDMS tot je beschikking, maar ik mis bij die hstore engine dingen als een native map/reduce, echte document storage etc.

En dan nog een dingetje, stel dat je ook al je product data als leaflets, images, etc in je DB zou willen stoppen, zit je met het volgende.

In the current implementation, neither the key nor the value string can exceed 65535 bytes in length; an error will be thrown if this limit is exceeded.

Al met lijkt mij persoonlijk die hstore wel leuk voor een speel project, maar imho is het een beetje fietsenmaker oplossing die ik nog niet in een productie omgeving zou in durven zetten.

Een snelle google op hstore met postgresql leverde mij in ieder geval niet heel veel op, nu zegt dat natuurlijk niks over het gebruiksgemak, maar wel wat over het gebruik ansich.

(als ik dat vergelijk met toch een aantal grote namen in de mongoDB productie sites) Nu kan het zo zijn dat mongoDB gewoon betere marketing heeft, maar op een of andere manier geeft hstore mij niet het robuuste gevoel wat ik bij postgresql wel heb

[SH4D3H]

kwaakvaak_v2 schreef op vrijdag 18 juni 2010 @ 07:33:
Maar waarom, zoals mensen hierboven ook al schrijven, het feit dat je geen aanpassingen aan je datamodel hoeft te doen als je een product een extra eigenschap erbij krijgt, je het product gewoon als volledig object zo mongo in kunt schieten, je zelf je ID kunt samen stellen, en als je wat meer meta informatie aan een een document je er nog steeds makkelijk (en bizar snel!!) een query op los kunt laten;

code:

find({'product.kleur' => 'blauw'});

Klinkt heel handig, maar dan krijg je alsnog veel dubbele data in de db.
Of acht je het voordeel dermate groot dat dat dan weinig uit zal maken?

Ik ga ook nog even aan de slag met de input van mithras & Soultaker, hoewel ik me Confusion aansluit dat ik hier niet teveel tijd aan wil verprutsen. Uiteindelijk gaat het ook niet om een concurrent van Amazon

[creator1988]

Als je een NOSQL oplossing wilt gebruiken, heb je sowieso ook een datastore nodig in een wél SQL based systeem, want je gaat transacties nodig hebben om je bestellingen etc. op te slaan.

Verder wil je voor productdata niet álles in bijvoorbeeld Mongo hebben staan vanwege historie, dus ook dit stuk wil je waarschijnlijk opslaan in een SQL based systeem (je moet ergens de absolute 'waarheid' hebben staan, en hier heb je referentiele integriteit nodig). Je zou dus eerder zoiets nodig hebben:



In je 'waarheid' database heb je views die de detailweergaves kunnen regelen. Eventueel zou je hier weer een frontend database kunnen hebben die dit min of meer cachet voor je. In de waarheid sla je dus wel alles in losse tabellen op.

Je search provider zou ik dan eerder iets verwachten als SOLR of FredHopper die juist hier heel erg goed in zijn i.p.v. Mongo.

Ik begrijp dat NoSQL databases de hype van het moment zijn (twee jaar geleden had je er niemand over gehoord)

Ook vroeger werden voor faceted search oplossingen bedacht, maar pas de laatste tijd zijn er bewezen oplossingen. Onze faceted search is retesnel, maar zeer ingewikkeld aan de backend en niet flexibel. Wij willen op termijn ook naar SOLR over.

[ Voor 16% gewijzigd door creator1988 op 21-06-2010 12:32 ]

[kwaakvaak_v2]

SH4D3H schreef op zondag 20 juni 2010 @ 17:09:
[...]

Klinkt heel handig, maar dan krijg je alsnog veel dubbele data in de db.
Of acht je het voordeel dermate groot dat dat dan weinig uit zal maken?

Dubbele data is niet de grootste ramp voor een database, iets helemaal plat normaliseren en daardoor een aantal joins in een statement te moeten maken kan duurder zijn als een extra regel in een tabel.

[creator1988]

kwaakvaak_v2 schreef op maandag 21 juni 2010 @ 13:22:
[...]


Dubbele data is niet de grootste ramp voor een database, iets helemaal plat normaliseren en daardoor een aantal joins in een statement te moeten maken kan duurder zijn als een extra regel in een tabel.

Desondanks wil je de data wel ergens helemaal genormaliseerd hebben staan. Je kan aparte frontend databases / indexed views hebben waarin dit platgeslagen wordt.

[kwaakvaak_v2]

creator1988 schreef op maandag 21 juni 2010 @ 13:58:
[...]


Desondanks wil je de data wel ergens helemaal genormaliseerd hebben staan. Je kan aparte frontend databases / indexed views hebben waarin dit platgeslagen wordt.

Ik heb die behoefte zelf eigenlijk nooit gehad, kun je uitleggen waarom je dat wel zou willen hebben?

Als je structuur uit je objecten (die dus in code leven) zit, en je hebt een datamodel, waarom zou je dan een schaduw frontent DB willen hebben? Puur voor de snelheid? Dat is toch juist de kracht van het noSQL model? Je schiet een entity als document ergens in, en het komt er razendsnel weer uit. Zeker in mongoDB was ik verbaast over hoe snel ik dingen terug kon vinden in mijn testomgeving (mbp met xampp)

[creator1988]

kwaakvaak_v2 schreef op maandag 21 juni 2010 @ 14:17:
[...]


Ik heb die behoefte zelf eigenlijk nooit gehad, kun je uitleggen waarom je dat wel zou willen hebben?

Als je structuur uit je objecten (die dus in code leven) zit, en je hebt een datamodel, waarom zou je dan een schaduw frontent DB willen hebben? Puur voor de snelheid? Dat is toch juist de kracht van het noSQL model? Je schiet een entity als document ergens in, en het komt er razendsnel weer uit. Zeker in mongoDB was ik verbaast over hoe snel ik dingen terug kon vinden in mijn testomgeving (mbp met xampp)

Omdat je data-integriteit wél belangrijk is in je datastore. Het gaat namelijk niet alleen over 'eenvoudige' data, maar ook over versioning van je rows, beheer van je servers, wellicht log shipping, backups, etc. Juist als je webwinkel je core business is, wil je dat dit soort data áltijd betrouwbaar is.

Je slaat je data hierna plat naar de frontend (dit kan overigens prima Mongo zijn, maar dus ook een losse frontend db / indexed views etc.), en naar je index-server (bijv. SOLR). Je index-server kan je ook niet écht zonder, want juist in een webwinkel heb je veel behoefte aan advanced-thingy's like faceted search.

Op deze manier moet je je vooral bezig houden met de echte datastore. De frontend kan omvallen, maar je hebt altijd integere data van waaruit je heel snel een nieuw frontendcluster kunt opbouwen.

[D-Raven]

Om even terug te haken op de vraag: "Hoe zouden jullie producteigenschappen opslaan in een database?"

Ik werk dagelijks met dit probleem, en wij hebben een database model die wellicht door Soultaker het eenvoudigst en het beste beschreven wordt.
Je moet wel in de gaten houden dat je een duidelijk verschil maakt tussen product eigenschappen en product informatie.
Product eigenschappen zijn bijvoorbeeld de lengte, breedte, kleur, gewicht, etc.
Maar niet dingen zoals voorraad gegevens, prijs gegevens, logistieke gegevens.

Je zou zelfs zover kunnen gaan door een verschil te maken tussen een product en een handels artikel. Waarbij een handels artikel naar een product verwijst, maar in feite gewoon een andere verpakkingsvorm van dat product voorstelt.

Maar wat Soultaker voorstelt werkt veruit het makkelijkste. Daarbij in acht nemende wat RobIII al zegt over het querien over ranges van waardes. Ik vergis me dit is geen probleem. Je kunt namelijk immers gewoon zeggen geef mij maar alle producten terug waarvan de eigenschap x is en de waarde tussen y en z ligt.

Als je echt Range waardes wilt definieren op je eigenschap dan kun je een extra kolom toevoegen aan je producteigenschappen, ipv waarde, heb je dan minValue en maxValue. Waarbij minValue de standaard waarde is en maxValue alleen wordt gebruikt als je een range van waardes opslaat. (vanuit gaande dat je genoeg hebt aan opeenvolgende reeksen).

Maar als je helemaal loos wilt gaan zou je naar het EAV model kunnen kijken. Al is dat wellicht overkill

[ Voor 25% gewijzigd door D-Raven op 24-06-2010 11:37 . Reden: uitbreiding ]

[messi]

creator1988 schreef op maandag 21 juni 2010 @ 14:40:
[...]


Omdat je data-integriteit wél belangrijk is in je datastore. Het gaat namelijk niet alleen over 'eenvoudige' data, maar ook over versioning van je rows, beheer van je servers, wellicht log shipping, backups, etc. Juist als je webwinkel je core business is, wil je dat dit soort data áltijd betrouwbaar is.

Je slaat je data hierna plat naar de frontend (dit kan overigens prima Mongo zijn, maar dus ook een losse frontend db / indexed views etc.), en naar je index-server (bijv. SOLR). Je index-server kan je ook niet écht zonder, want juist in een webwinkel heb je veel behoefte aan advanced-thingy's like faceted search.

Op deze manier moet je je vooral bezig houden met de echte datastore. De frontend kan omvallen, maar je hebt altijd integere data van waaruit je heel snel een nieuw frontendcluster kunt opbouwen.

Ik zie hier nog niet echt een reden in staan om géén NoSQL database te gebruiken. Versioning e.d kan prima met een document based DB. Ook transactions zijn geen probleem, een database server als Mongo slaat het hele document in een keer op (bijv. je order met alle order regels en product informatie) en met atomic operations kun je er voor zorgen dat alle sku's netjes in een keer geupdate worden.. (zie ook: http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/)

Met het platslaan van de data in de frontend krijg je weer zat nieuwe problemen erbij. Wanneer ga je de data platslaan? in de achtergrond of als de eerste bezoeker op die pagina komt? enz.

Let wel dat iets als mongodb absoluut geen veredelde memcache is en dat zaken als backups, sharding clustering, master/slave en de beheer tools al behoorlijk goed werken.