Storing large JSON strings in SQL Server using WebAPI

Question

I have a running project using WebAPI and EF code-first.

The database is currently working properly with many tables and relationships set up. However, all my data types are handled as JSON on the client and I don't need to set up extra table for each new nested object in a JSON on the database.

So just as general info, is it bad practice to implement the following example?

object foo

id (primary key)
value (nvarchar(max)) <- I will store the JSON as string in that column.

assuming foo has many nested objects as such { 'obj1': '1', 'obj2': [ '123', '456' ] } etc...

Would that be a good idea? Instead of having obj1 as a different table and making the relationship back to foo.

Thanks

Certainly this is possible, but if you have consistent data it will be MUCH better to actually deserialize the json into actual tables and columns. Also, if you can get to Sql Server 2016, there is (finally) some built-in json support available. — Joel Coehoorn
I guess it depends, do you need to query the json? If so that will be slow/difficult. As a note mssql 2016 will support json as a native data type. — dmeglio
Another option for storing JSON is using PostgreSQL that has built-in JSON support postgresql.org/docs/9.3/static/functions-json.html. Just only one problem exists - EF can not work with PostgerSQL without tuning. — feeeper
What if someone invents a new serialization protocol? Maybe a bit far fetched, but basically you're freezing a transport implementation into a store definition. More realistically: what if you want to expose your data to other parties/APIs, e.g. BI tools? — Gert Arnold