5 ms·

What 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 eith

by ris 11y ago

What 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 ago
According 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 ago
  Legal 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 ago
  I 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.

by ris 11y ago

What 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 ago

According 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 ago
Legal 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 ago
I 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.