SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Putting JSON on an equal footing to XML


Putting JSON on an equal footing to XML

Author
Message
Phil Factor
Phil Factor
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2742 Visits: 2986
Comments posted to this topic are about the item Putting JSON on an equal footing to XML


Best wishes,

Phil Factor
Simple Talk
daniel 16765
daniel 16765
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 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
RobertYoung
RobertYoung
SSC-Enthusiastic
SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)

Group: General Forum Members
Points: 164 Visits: 232
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.
emmchild
emmchild
SSC-Enthusiastic
SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)

Group: General Forum Members
Points: 164 Visits: 408
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 ;-) .



emmchild
emmchild
SSC-Enthusiastic
SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)

Group: General Forum Members
Points: 164 Visits: 408
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.



RobertYoung
RobertYoung
SSC-Enthusiastic
SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)SSC-Enthusiastic (164 reputation)

Group: General Forum Members
Points: 164 Visits: 232
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.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)

Group: General Forum Members
Points: 114855 Visits: 41397
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
chrisn-585491
chrisn-585491
SSCrazy
SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)

Group: General Forum Members
Points: 2588 Visits: 2471
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.
peter-757102
peter-757102
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1063 Visits: 2559
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!
Phil Factor
Phil Factor
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2742 Visits: 2986
@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
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search