DBJSON: SELECT * FROM persons AS JSON

Conclusion

All in all it is clear that this kind of a protocol and notation, is much more forgiving than SQL. The syntax is well known, powerful and simple in the same time. Because this is just JavaScript.  In the same time, opposite of SQL, DBJSON is message “packaging” protocol, allowing for unlimited nesting, presence of functions, etc. Great care was taken to make all of this flexibility available but still not wildly foreign to standard relational databases, and their users.

At the end of the day, DBJSON protocol is a question of a contract between message sender and message consumer.

The whole web applications community will have to make an effort to decide and standardize on one single and consistent DBJSON protocol specification. In the same time carefully avoiding to fall into the “jack of all trades” trap, DBJSON must not become “a little bit for everyone, but not enough for anyone”.

Further Reading

Mapping Between JSON and XML:  http ://msdn.microsoft.com/en-us/library/bb924435.aspx


DBJSON(tm) idea is by no means finished. I am working on it right now.

(c) 2009-2012-2016 by DusanB. Jovanovic


1: That is not true. The MIME media type for JSON text is application/json . The default encoding is UTF-8. (Source: RFC 4627). RFC 4627 — The application/json Media Type for JavaScript Object Notation (JSON)

6 Replies to “DBJSON: SELECT * FROM persons AS JSON”

  1. I Like the idea very much. I think the bigger problem in the short term is that web browsers aren’t secure so you couldn’t use DBJSON to expose your database directly or else anyone could run any query they wanted to by hacking the JavaScript. It could work out of the box with Aptana’s Jaxer, with Rhino, or maybe even with Adobe AIR where the JavaScript runtime is more in the developers control. I’ll be interested to see how this goes.

  2. Thanks Ian,

    Text currently (05Nov08) on the blog contains a good idea but is shamefully chaotic, I know.

    The comment you made on the security is of course valid. Answering it properly opens a “can of worms” which is called : Server Side JavaScript ;o)

    I certainly would not allow my team to send SQL select statements from a browser page back to the RDBMS.
    But server side components written with JavaScript are an entirely different matter. Also.
    I can easily envisage an architecture where client-to-server selections are totally removed. And client-to-client_data selections are totally ok. Like TAFFY does.

    Interesting near future development are client side DB-s, full blown but lightweight , like SQL CE 3.5 SP1, etc … This is where client app talks to the local DB which is transparently synchronized with separate infrastructure with a DB back end, over the wire. I can immediately (today) write AJAX app which will run inside HTA pages and talk to the local SQLSVR CE3.5. Only DBJSON mediator is missing ;o)

    PS: DBJSON can have a secondary but still usefull role here: as an security broker/mediator.

    Regards: Dusan

    1. Zoom to March 2016: Who would think that NODE.JS would look so uncertain and distant, way back in 2008?

      But ok, I was not very far of the mark with “Server Side JavaScript” :)

  3. Very true. In fact I think Server Side JavaScript with tools like this has a really bright future and makes a lot of sense. Looking forward to seeing how this goes.

  4. @shadowbq : Thanks for your somewhat terse comment ;o)

    JavaScript in “CouchDB” is partial implementation of the “MapReduce” concept and framework.
    ( http://en.wikipedia.org/wiki/MapReduce )
    And on “MapReduce”, I am affraid I largely agree with David DeWitt and Michael Stonebraker, pioneering experts in parallel databases and shared nothing architectures. In short: thumbs down.

    I am talking here about ubiquitous add on to current SQL syntaxes inside RDBMS-es, which would be a key to people adopting and understanding JSON.

Comments are closed.