Ozzie.eu

Seems I’m not the only one keeping away from JSON on the relational DB:

I would shy away from the NoSQL add-ons that some relational vendors have added, to compete with their newer database cousins. This starts to feel like a fashion contest after a while.

You can also get my point of view on this matter:

• JSON on MySQL: still not fond of it.
  
• JSON on the database? No thanks!
  

Earlier, I posted here about my dislike of allowing developers to push the JSON workload into the database server.

Reading this entry on a nice blog about MySQL, what caught my eye was the sentence:

Funny. It all started with the idea to be schema-free. Now people seem to need schema enforcement.

I’ve also seen this article on DZone which sarcastically illustrates the mislead of developers caused by the hype on JSON:

That’s it, then; let’s use JSON and manifest the death of XML!

I got reassurance on Twitter that MySQL performance won’t be compromised for using the new JSON datatype and operations:

@mjlmo I would like to see it be inc. in the standards (where it is currently being discussed). Overhead is well amortized by IO on insert.

— morgo (@morgo) September 10, 2015

Not wanting to flog a dead horse here, by coming back to this topic, but it’s really not about the features or how they perform well on the engine. It’s what developers come up with to make things work. 

Apparently, already there are bright minds that would like to cripple the flexibility of JSON with a sort of schema validation. Who knows what else will come up? And since the door is open to shove all that bright ideas inside the database engine, might as well make developers at home and put it up to them to solve the upcoming performance issues later on.

JSON is a wonderful thing for developers. It’s becoming more and more the de facto standard for information interchange and asynchronous operations inside applications. So much so that database engines are integrating it on their latest release. Examples of that are:

• MySQL 5.7: The JSON datatype
  
• 
  
  Microsoft SQL Server 2016: JSON Data
  

I wont even challenge the advantages and performance measurements on such primitives, but both from a database administrator perspective, as well as a developer’s one, I think this is a bad idea!

The major pitfalls on using this native integration would be:

1. Injecting database vendor dependency on the application, since these enhancements work on specific primitives not part of SQL;
   
2. Processing expense and memory allocation is shifted on to the database server, whose main role should be serving data not formatting or performing interpretations from it.

So you might end up with a great application that uses the most recent features from your specific RDBMS but from then on you are stuck with it and hope you don’t forget to perform the server sizing including the JSON processing load.