Hacker News Reader

Comment by liotier | Hacker News Reader

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.

View on HN

Well 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.

and you also cannot have secondary indexes that way

Document as a blob, with identifiers and foreign keys surrogates as their own fields - OK, I could live with that hybrid approach.

CouchDB gives you /real/ transactions, they just don't span multiple documents.

Well that's not real transactions - that's ACID compliance...

If 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.

Reply on news.ycombinator.com