Google+ Followers

zondag 24 augustus 2014

HSTORE, JSON en het relationele datamodel.

Onlangs zei iemand tegen mij dat datatypen zoals HSTORE en JSON strict genomen niet thuishoren in een relationeel datamodel en dat zij die het wel gebruiken dus fout bezig zijn.

Het antwoord dat ik hem gaf plaats ik ook hier, met wat extra's.

HSTORE is niet bedoeld voor data waarin relaties afgedwongen moeten worden. Het is bedoeld voor data die "schemaloos" is. Echte schemaloze data bestaat niet (hoe zou je data moeten verwerken als je geen idee hebt wat het formaat van de data is?) maar er bestaat wel data waarvan het schema complex of veranderlijk is waardoor het niet meer realistisch is om het schema uit te werken en de data op te slaan in een genormaliseerd datamodel.

Voor díé data is HSTORE bedoeld. Via HSTORE kun je willekeurige data in een record opslaan als key/value pairs.

Het klassieke voorbeeld van data sie in een HSTORE thuishoort zijn producteigenschappen. Elke fabrikant levert zijn eigen lijst van gegevens over een product. Sommige gegevens worden door alle fabrikanten meegegeven, anderen alleen door bepaalde fabrikanten. Het is niet realistisch om een lijst op te stellen van alle mogelijke attributen die een fabrikant mee zou kunnen gaan willen geven, dus als je deze data wilt kunnen opslaan dan kom je uit op een Entity-Attribute-Value tabel, een tabel met het id van het product, de naam van de eigenschap en de waarde die de fabrikant voor die eigenschap meegeeft.

Voordeel van een EAV tabel is dat je er alles in kwijt kunt als een key/value pair, nadeel is dat je de values niet relationeel kunt verbinden aan een tabel van toegestane waarden, omdat je niet weet onder welke key de fabrikant een eigenschap gaat aanleveren en al helemaal niet in welk formaat de fabrikant de value aan gaat leveren, noemt hij de kleur van een broek "Blauw", "Azuur Blauw", of  "Tricky Blue"?

Wat dat betreft is het dus exact hetzelfde als een HSTORE; een key/value pair waarin je niets kunt afdwingen zonder kunstgrepen. De HSTORE is alleen ogelooflijk veel sneller om uit te lezen dan een EAV. Er komt geen subquery, JOIN of GROUP BY aan te pas.

Het JSON datatype doet daar nog een schepje bovenop omdat je JSON datastructuren die je bijvoorbeeld doorkrijgt vanuit een CMS direct op kunt slaan als JSON, terwijl de data wel indexeerbaar en doorzoekbaar is.

Uiteraard kun je alles wat HSTORE en JSON doen ook in reguliere SQL nabouwen, maar dat is complexer en de oplossing is uiteindelijk trager.