Non-Relational Web DB Interoperability
17 December 2007Alex Russell recently wrote about the advantages of non-relational (dynamic object) databases for application development. The flexibility of using dynamic persisted objects that behave like dynamic OOP objects provides a great level of agility in progressive iterative development. Objects can automatically be persisted, virtually eliminating the overhead of developing around a database. I certainly am a proponent for this type of application development, it is exactly what my project Persevere is built for.
Alex also talked about a number of other offerings including SimpleDB and CouchDB that can provide database services through web/HTTP interaction. While of course, I think Persevere is further along and more powerful than these other systems (with full client and server automated orthogonal persistence, function storage, JSONP, JSONPath, JSON Schema support, and more), I think that even more important than trying persuade the superiority of one system, is to espouse the benefits of interoperability of these systems. It is highly unlikely that one web service DB is going to be a monopoly anytime soon. With the availability of multiple web services, sites will certainly want to take advantage of varied web services and mashups will quickly grow in popularity. The cost and difficulty of these mashups will hinge largely on what degree of interoperability exists between these web services.
When using databases that are particularly suited for persisting dynamic object/map style data, JSON is certainly an obvious choice for interoperability, simplicity, and adoption. In addition, we have one of the most widely adopted standards on the planet available to us in the REST HTTP vocabulary (GET, POST, PUT, and DELETE). These HTTP methods in combination with JSON can provide a very simple intuitive interface for many basic database operations. While SimpleDB uses REST HTTP methods, unfortunately it does not seem to be based on JSON. However, both Persevere and CouchDB indepedently came to use this JSON REST approach for database interaction, and conseqently have a very high level of interoperability opportunity.
The basic HTTP verbs provide a broadly accepted standard for basic database operations, but generally queries entail more power and sophistication than simple id based GET requests can provide. SimpleDB defines it’s own query language. CouchDb does not have a query language (as far as I can tell), but rather relies on server side JavaScript mapping functions. Persevere uses JSONPath for it’s query languages and also supports server side JavaScript mapping functions. JSONPath seems to be an emerging standard, and as mentioned in the last post, will probably even be included in Dojo in the future.
I believe it is important that these different web storage engines both continue to innovate and evolve, but also work hard to find opportunities to work together for interoperability as well.
2 Responses to “Non-Relational Web DB Interoperability”
December 18th, 2007 at 12:57 pm
This is one of the hardest ideas I have come to see in JSON. I have personally worked with SQL and XML for years and relational / document mapping is in my blood. It is hard to transition THINKING in disparate JSON objects ( I can translate but not originate in JSON)
What I have found is some view that JSON databases are defined by COLUMN rather than ROWS as in mySql. How does this work out?
Another feature I have not had time to look into is ‘Auto-linking’ - Say I have the following JSON objects:
{id: 555, name: ric, age: 38} and I UPDATE {id: 555, name: ric, height: 6.0} - which systems CREATE two separate objects and which just add an extra property to the one entity?
May 12th, 2008 at 12:37 pm
9f00b845368d…
9f00b845368d423a8614…