3 ms·
Why would anyone store JSON data in a relational database, thus losing the opportunity to join with the objects kept as JSON data ? I guess that I like normaliz
by liotier 14y ago
Why would anyone store JSON data in a relational database, thus losing the opportunity to join with the objects kept as JSON data ? I guess that I like normalized data too much and that some people have performance constraints, but still - a denormalized tables solves that problem and keeps output formatting sanely out of the data model.
- meaty 14y agoWell technically you don't join (document store approach) or you keep your IDs and FK's as surrogates outside the JSON blob and use them as indexes only (hyprid mongo-ish store). What it does give you is a JSON object store with somewhat better stability and real transactional guarantees compared to say CouchDB or MongoDB. However, the issue I have with this approach is more that there is some opportunity to add more processing into the database black box, which is expensive to scale up. I'd rather it wasn't type aware of JSON (i.e. it was just a varchar(max) column) and all that processing sat in the application itself which is cheap to scale out.
- alexro 14y agoand you also cannot have secondary indexes that way
- liotier 14y agoDocument as a blob, with identifiers and foreign keys surrogates as their own fields - OK, I could live with that hybrid approach.
- klaruz 14y agoCouchDB gives you /real/ transactions, they just don't span multiple documents.
- meaty 14y agoWell that's not real transactions - that's ACID compliance...
- scubaguy 14y agoIf your master data source is JSON, then you can store your raw data as JSON and be able to do ad-hoc queries against it. At the same time, you can break your JSON into relational tables so you can also operate on it in traditional ways.