JSON is a serialization format, not a database schema. We went through this exact same thing with XML, also widely supported as a type in relational databases. Some people didn't understand that XML is not a database and went ahead to write all kinds of nonsense around it. JSON is far less rigorous (and far less bloated) than XML, it's closer to a CSV file. It's a great format for a lot of things but it's not a database.
From the Wikipedia article on JSON, right at the top: "JSON (JavaScript Object Notation) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays (or other serializable values). It is a common data format with a diverse range of functionality in data interchange including communication of web applications with servers."
Looks like JSON schemas are in the works, so we'll probably go through the whole XML as a database bullshit all over again.
I have never seen this implemented or used but I'm not deep into the JSON world. This looks to me like "XML as a database" all over again, but correct me if it has some other application. There's nothing wrong with XML or JSON schemas, but they are not equivalent to a relational schema -- they are more (properly) used for validation and standardization, i.e. for a data interchange format both sides need to agree on the schema. An interchange format is not a database, it's a representation of things that might be retrieved from or stored in a database.
If choose to organize your data using a relational model and then choose not to normalize that relational design you're doing it wrong.
Some of the benefits you get by doing proper normalized include:
* Avoids repetitive entries and duplicate data.
* Helps reduce the storage space required.
* Prevents the restructuring of the database to accommodate new requirements.
* Prevents the need for coding changes to accommodate new requirements.
* Increases the speed and flexibility of queries.
With a poorly normalized relational design you are throwing away the essence of the 'relational' model and
that 'relational' concept is right there in the name, RDMS.
Normalizing allows enforcing referential integrity and reduces/eliminates update anomalies. Those seem like theoretical concerns until your data gets corrupted.
Surely since you agree normalization helps to 'reduces/eliminates update anomalies' then that also means it's going to reduce the chance of data corruption?
Also what type of software design and development is not based on theoretical concerns?
Software developers spend years studying theory in the hope they can use that knowledge in their own designs.
Now I don't disagree normalization is a 'theoretical exercise' but it is also a helpful tool/technique that will make your life easier.
I think you misunderstood my comment. I have heard developers dismiss normalization as a theoretical concern. It’s not. Normalizing prevents update anomalies, for one thing. That’s not the same as “data corruption.”
In my experience most software developers don’t spend years studying theory. They spend hours studying buzzwords and fads.
By skipping the normalization steps you end up with a design that is far from optimal.