Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Putting JSON on an equal footing to XML Expand / Collapse
Author
Message
Posted Saturday, February 18, 2012 7:31 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 577, Visits: 2,503
Comments posted to this topic are about the item Putting JSON on an equal footing to XML


Best wishes,

Phil Factor
Simple Talk
Post #1254400
Posted Sunday, February 19, 2012 1:04 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, April 15, 2012 4:49 AM
Points: 1, Visits: 12
Couldn't agreed more. Been waiting for native built in JSON parser into MSSQL for a while now. With subindexing of the members and the ability to apply javascript predicates to documents. Doing that, Microsoft would position them selves into a document oriented db world with a standard product. As I said. Been wanting this as I run an OSS project http://sisodb.com that would look really different if that suport was built in. Then SisoDb would just be an addon to native ADO.Net

//Daniel
Post #1254407
Posted Sunday, February 19, 2012 4:20 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 5:49 AM
Points: 76, Visits: 231
I can no longer find a cite, but Fabian Pascal once made the obvious point: xml is not in any meaningful way "self describing", for if it were both the sender and receiver of data streams would need no explicit coding. Of course, that's bunk. The structure of the data must be known by both, and since that knowledge exists, then the smallest overhead in the data stream wins. By that strict criterion, csv (or fixed column) wins. If data need be somewhat interpretable, then JSON is the least confusing. JSON also mediates silly hierarchies, which is a good thing.
Post #1254487
Posted Sunday, February 19, 2012 6:46 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, June 7, 2014 7:51 PM
Points: 42, Visits: 351
I agree 100%. Look at fastjson. It's better than anything Microsoft has for object serialization. I cringe every time someone mentions XML and SQL Server in the same breath. Microsoft needs to get there act together or SQL server is not going to be a very good choice for service oriented solutions. Supporting Jason would make ado.net a solid data access choice. Object relational mapping would be much better sign native Json support.

Customers wanted XML support so that is what they got. The rest of the world is using json efficiently and leaving sqlserver in the dust. Phil I think we both know json support will be in SQL 2016 which is slated for release 4 years from now. Maybe red gate can sell me something in the meantime .



Post #1254501
Posted Sunday, February 19, 2012 6:55 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, June 7, 2014 7:51 PM
Points: 42, Visits: 351
The book you mentioned cites "Create SOAP endpoints for use in web services applications" like that is a good idea. XML based soap endpoints cause so much pain for enterprise developers. Its the high blood pressure of enterprise development. Google the topic and prepare yourself for the endless tales of sorrow. I really couldn't let this go without pointing out that soap is bad.



Post #1254502
Posted Sunday, February 19, 2012 6:58 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 5:49 AM
Points: 76, Visits: 231
emmchild (2/19/2012)
Customers wanted XML support so that is what they got. The rest of the world is using json efficiently and leaving sqlserver in the dust. Phil I think we both know json support will be in SQL 2016 which is slated for release 4 years from now. Maybe red gate can sell me something in the meantime .


MS wasn't the only DB vendor to get on the xml train when more useful functionality could be added. IBM did about the same thing with DB2/9.
Post #1254503
Posted Monday, February 20, 2012 6:20 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:17 AM
Points: 36,800, Visits: 31,261
RobertYoung (2/19/2012)
I can no longer find a cite, but Fabian Pascal once made the obvious point: xml is not in any meaningful way "self describing", for if it were both the sender and receiver of data streams would need no explicit coding. Of course, that's bunk. The structure of the data must be known by both, and since that knowledge exists, then the smallest overhead in the data stream wins. By that strict criterion, cvs (or fixed column) wins. If data need be somewhat interpretable, then JSON is the least confusing. JSON also mediates silly hierarchies, which is a good thing.


Heh... Robert Young for President!


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1254696
Posted Monday, February 20, 2012 6:51 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Yesterday @ 6:16 AM
Points: 628, Visits: 1,607
MS wasn't the only DB vendor to get on the xml train when more useful functionality could be added. IBM did about the same thing with DB2/9.


Vendors sometimes jump on "standards" and miss the point of supporting better tools,techiques and utilities. As a developer I wonder who makes these decisions that can lead to local optima. Currently I see interest in the SQL Server source control that support SVN and doesn't take in consideration of more advance tools like Mercurial or git.
Post #1254715
Posted Wednesday, February 22, 2012 10:00 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:18 AM
Points: 323, Visits: 2,200
Silly hierarchies?

I know a lot, if not most people creating XML are quite bad at the modeling and encoding part of their data. For example, nearly all XML documents I get shipped to me use child elements where they are absolutely not needed and even unwanted. People don’t seem to know what cardinality implies or what it means for modeling when data cannot be subdivided any further. As such there seems to be a mythical belief out there that everything must be modeled as a child element, even where an attribute would be so much more appropriate.

Attributes are faster, they can be uniquely indexed and are local to the element without causing xpath navigation overhead when traversing a document. Also, in desterilized form they are a LOT faster to work with because of these attributes. Not to mention the benefits when partially parsing a document like with sax.

Then there is encoding, I get swamped at work by parties that deliver XML full of encoding errors, cause by people building XML without a DOM or any knowledge of the really simple structure of XML. People do not even seem to understand the difference between the elements and the data that is contained within them. I am not kidding you!

None of this however is in any way a structural problem of XML and the related co-languages (xpath, xslt, xlm schema, etc.). The problem lies with people that should not even be driving a slow car, trying to be behind the wheels of a formula 1 car!

JSON is no different for those people really, they just can skip the whole modeling part and send garbage in just another format and that does not solve any of the mentioned problems. It is worse readable by humans (no clear formatting for example), and it manages to be worse than that for machines to process (is there a simple sax parser equivalent for large streams?). The only thing it really shines at is serialization of relatively small chunks of barely structured data. It absolutely does not deserves any place in a relational database as a datatype!

Once a ‘structure’ is in JSON format, it pretty much is useless until you unpack it to memory and navigate it procedurally.

Don’t even get me started about type safety …

The only reason JSON gets used so much is because it originated from a more and more used platform called the browser. Something which in itself is causing more than a few issues in how applications are developed. You would have thought it would been figured out by now, but the staggering explosion of new ‘technologies’ around it to mitigate/contain the damage that is done and is part structural, just proves my point.

But obviously www.json.org instead writes:

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate.

The first being an outright lie IMO, the second one simply neglects to mention that parsing comes in many forms. Serialisation/deserialisation in my view is just a minimal form of parsing akin to CSV/TSV and fixed position flat files. And it is in my opinion easier to generate and parse XML then it is to do it for JSON, especially the escaping for xml is less cumbersome. On top of that XML knows things such as CDATA, where whole blocks of text can be in unencoded form instead of layering encoding over encoding in strings that are part of an array or structure such as the case in JSON.

From nearly every point of view, Microsoft made the right choice and I hope they stick to it.
Unstructured and/or hard to process data like JSON should just be stored as blobs and we have the tools for that if we choose to do so. The next version of SQL Server has much more flexible file system integration and in the meantime anything can be stored in varchar(max) as well.

For the diehards, let them write their own .NET datatype and extend SQL Server if they think it really solves anything! In my eyes, there are far more important issues that the Microsoft SQL team need addressing!
Post #1256118
Posted Wednesday, February 22, 2012 11:41 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 577, Visits: 2,503
@peter-757102
I agree with you that XML is a much more mature product, and JSON has many glaring holes in it (DateTime?). However, I hope that I didn't imply that I thought that JSON was intrinsically superior. Few of us as database developers actually get the choice about the markup that gets thrown at us. I'd much rather get the attempt at a serialized object from an application than submit to the horror of application developers attempting the translation into a relational form themselves. If the application's dialect is JSON, I'd just like to be able to cope with it, and I don't currently have all the tools. Sure, I can tell the application developers to 'persist' their stuff in XML instead of JSON, but they're not going to obey me! It's hardly surprising that they insist, since JSON is a much easier way to serialize a JavaScript object than XML you just use JSON2-js (JSON in JavaScript). To convert an object to JSON, they can use the JSON.stringify function and create a javascript object from a JSON string is as simple as going var my_object = JSON.parse(my_json_string); Thankfully, there isn't so much margin of error here for the rookie programmer!



Best wishes,

Phil Factor
Simple Talk
Post #1256195
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse