4 ms·
We already have a not-particularly-transaction-safe JSON database in MongoDB. When postgres added JSON operations it brought the sanity and robustness of its d
by ris 11y ago
We already have a not-particularly-transaction-safe JSON database in MongoDB.
When postgres added JSON operations it brought the sanity and robustness of its database engine to the wild west of document stores.
What's MySQL bringing?
- dozzie 11y agoThe usual thing, the try to catch up with Postgres from five years ago.
- threeseed 11y agoPostgreSQL only supports indexing for JSONB so actually MySQL is ahead here.
- ris 11y agoWhat functional difference does this make? Do you really want to keep your JSON formatting? My guess is all MySQL does is create a shadow JSONB-like format either in-table or in the index.
- threeseed 11y agoAccording to here: http://www.postgresql.org/docs/9.4/static/datatype-json.html http://www.postgresql.org/docs/9.4/static/datatype-json.html PostgreSQL doesn't preserve key ordering and strips multiple key/values pairs. I know some systems we have insist on JSON documents having a set order sequence. Also there are often legal reasons why you need the raw, unmodified data preserved.
- mbesto 11y ago> Also there are often legal reasons If you business has legal implications on your database format, then why would you trust a NoSQL implementation? For example - financial transactions: https://twitter.com/seldo/status/413429913715085312 https://twitter.com/seldo/status/413429913715085312
- olalonde 11y agoLegal reasons such as? Not doubting you, genuinely curious.
- uxp 11y ago> I know some systems we have insist on JSON documents having a set order sequence. I've had to deal with these kinds of systems before, and they are a giant pain in the ass, usually doing some kind of string parsing on the JSON blob or other asinine fake-parsing. While I'd normally agree with you in premise, you're asking for an edge case that doesn't conform to the spec. Additionally, the easiest way to keep the raw, unmodified data preserved, yet still be able to operate and potentially change that data, is to duplicate the data. As soon as that data hits your system, throw it in an immutable TEXT column that your warehouse can suck up and store indefinitely, then normalize and mutate the hell out of it in your operational database, all the while keeping an 'original_data' key back to the raw text. Problem solved.
- prodigal_erik 11y agoI can't imagine a sensible use case for a pseudo-JSON literal structured like that. I don't believe I've ever used any parser that would preserve it, and it certainly isn't compatible with JavaScript. Anyone who cares about ordering of multiple values needs to change their schema to use arrays, or start with a less inappropriate format.
- eatonphil 11y agoWhy does that mean MySQL is ahead? Postgres supports JSONB and JSON. Aren't they just equal now?
- saurik 11y agoThe extremely limited "indexing" described by this MySQL documentation is absolutely supported by PostgreSQL's JSON type, and in fact has been for years now if you were willing to tolerate writing a couple lines of plv8 stored procedure. However, if you want the "actual indexing" (on arbitrary content, not just specific keys or lookup strategies) that PostgreSQL provides for JSONB on JSON columns, if you do a functional GiST index on a JSON column cast to a JSONB, you should find that PostgreSQL stores only the JSON but yet can index it "as if" it were JSONB. So, no: absolutely no benefit here.