Back when XML first appeared on the scene—we’re talking 1996—software developers began using it in many different areas, including data storage and transfer. It even spawned a few memorable lawsuits, one of which featured Microsoft in one corner. But XML also proved itself a bit of a headache for developers. It doesn’t map well to classes in C++, for example, and instead you drill down into it using various libraries. Nevertheless, programmers relied on it because of its simple, clean notation. If anything, XML proved an even bigger headache for database analysts. Its hierarchical nature doesn’t play well with SQL. But more and more software utilized it, and finally the vendors took note and added XML features to their databases. Around 2002, the SQL vendors began adding limited XML features—clunky ones, in many cases. Now, another 10 years have passed, and the vendors have finally started to introduce better XML features in their databases. Perhaps it’s too little, too late, because now software developers are embracing a different notation for transferring and storing data, one that maps much more nicely to structures in high-level languages: JSON, which stands for JavaScript Object Notation. JSON is essentially a data-only subset of JavaScript, and it works especially well with Web applications running in browsers, since the browsers easily understand JavaScript and, subsequently, JSON. Like XML, JSON still isn’t very well-suited for SQL databases, but there are several new databases that use it natively that are becoming more popular, such as MongoDB and CouchDB. Because JSON maps so well to data structures, various entity-modeling frameworks that map data structures to objects can also be used to map the structures to well-defined SQL schemas, allowing for the smooth movement of data from the front end (the browser) through the middleware (the server-side code) to the database, whether it’s an SQL database or a so-called NoSQL database such as MongoDB. The reason this is so vital to software development is it requires less coding. With most Web frameworks today, when a JSON object is sent from the browser to the server-side code, the programmer can access the data directly through a class. This is in contrast to having to write loops and drill down into XML. (However, in all fairness, some of the XML libraries are very easy to use and certainly efficient.) So what does JSON look like? Here’s an example: { "firstname": "George", "lastname" : "Washington", "presidency": [ 1789, 1797 ] } If this were JavaScript code, you could leave off the quotes around the names of the elements, such as firstname: "George". But JSON is stricter. Although some JSON parsers will be forgiving and allow you to leave off the quotes from the element names (or use single quotes instead of double quotes), technically the JSON (as defined in the IETF’s RFC-4627) requires double quotes. JSON does present some issues, specifically in JavaScript. JSON is supposed to be data-only, which means it should contain no actual JavaScript code such as function calls. One way to parse the JSON is using JavaScript’s eval function—and that’s where trouble arises, because eval will evaluate the code as if it’s JavaScript, functions and all. This can result in security issues. As such, all of today’s browsers now offer built-in JSON parsing functions. And for older browsers, there are free JSON libraries available that provide the exact same functionality. Conclusion All this isn’t meant to suggest that JSON is inherently “better” than XML, or that XML should be displaced by JSON. But I am suggesting is that, because more and more software developers are using JSON, database administrators should take note of its presence and consider it a possibility during the data-analysis stages of development. And business managers should be aware of it when mapping out development strategies, especially when considering the amount of time it saves developers, since the browsers already speak it. XML is sure to be around for a good bit longer, but we’re seeing JSON used a lot more, for good reason. Image: Pavel Ignatov/Shutterstock.com Why Database Administrators Should Consider JSON
Back when XML first appeared on the scene—we’re talking 1996—software developers began using it in many different areas, including data storage and transfer. It even spawned a few memorable lawsuits, one of which featured Microsoft in one corner. But XML also proved itself a bit of a headache for developers. It doesn’t map well to classes in C++, for example, and instead you drill down into it using various libraries. Nevertheless, programmers relied on it because of its simple, clean notation. If anything, XML proved an even bigger headache for database analysts. Its hierarchical nature doesn’t play well with SQL. But more and more software utilized it, and finally the vendors took note and added XML features to their databases. Around 2002, the SQL vendors began adding limited XML features—clunky ones, in many cases. Now, another 10 years have passed, and the vendors have finally started to introduce better XML features in their databases. Perhaps it’s too little, too late, because now software developers are embracing a different notation for transferring and storing data, one that maps much more nicely to structures in high-level languages: JSON, which stands for JavaScript Object Notation. JSON is essentially a data-only subset of JavaScript, and it works especially well with Web applications running in browsers, since the browsers easily understand JavaScript and, subsequently, JSON. Like XML, JSON still isn’t very well-suited for SQL databases, but there are several new databases that use it natively that are becoming more popular, such as MongoDB and CouchDB. Because JSON maps so well to data structures, various entity-modeling frameworks that map data structures to objects can also be used to map the structures to well-defined SQL schemas, allowing for the smooth movement of data from the front end (the browser) through the middleware (the server-side code) to the database, whether it’s an SQL database or a so-called NoSQL database such as MongoDB. The reason this is so vital to software development is it requires less coding. With most Web frameworks today, when a JSON object is sent from the browser to the server-side code, the programmer can access the data directly through a class. This is in contrast to having to write loops and drill down into XML. (However, in all fairness, some of the XML libraries are very easy to use and certainly efficient.) So what does JSON look like? Here’s an example: { "firstname": "George", "lastname" : "Washington", "presidency": [ 1789, 1797 ] } If this were JavaScript code, you could leave off the quotes around the names of the elements, such as firstname: "George". But JSON is stricter. Although some JSON parsers will be forgiving and allow you to leave off the quotes from the element names (or use single quotes instead of double quotes), technically the JSON (as defined in the IETF’s RFC-4627) requires double quotes. JSON does present some issues, specifically in JavaScript. JSON is supposed to be data-only, which means it should contain no actual JavaScript code such as function calls. One way to parse the JSON is using JavaScript’s eval function—and that’s where trouble arises, because eval will evaluate the code as if it’s JavaScript, functions and all. This can result in security issues. As such, all of today’s browsers now offer built-in JSON parsing functions. And for older browsers, there are free JSON libraries available that provide the exact same functionality. Conclusion All this isn’t meant to suggest that JSON is inherently “better” than XML, or that XML should be displaced by JSON. But I am suggesting is that, because more and more software developers are using JSON, database administrators should take note of its presence and consider it a possibility during the data-analysis stages of development. And business managers should be aware of it when mapping out development strategies, especially when considering the amount of time it saves developers, since the browsers already speak it. XML is sure to be around for a good bit longer, but we’re seeing JSON used a lot more, for good reason. Image: Pavel Ignatov/Shutterstock.com