SQL, NoSQL or SomeSQL?
Big Data has become one of today's significant trends with developers looking for software technology that permits developing scalable applications for the cloud, web or enterprise environments. Pushing the envelope on data set size, elasticity and scalability has been the catalyst for a debate over the merits of SQL databases and those collectively known as NoSQL databases.Because the NoSQL approach is recent, some might assume it offers more features than older database software. But, in reality, NoSQL solutions were designed for scalability and performance and not to offer feature sets comparable to the SQL platforms. The NoSQL DBMS typically differs from an object-relational DBMS, for example, in several areas. The cost of licensing is a major difference but the focus here is capability, not cost.
One major difference between a NoSQL or SQL solution is data consistency. SQL technology has been used for transactions with ACID properties (Atomicity, Consistency, Isolation and Durability). For providing massively scalable, distributed applications built with horizontal partitions, an alternative is to support BASE properties: Basically Available, Soft state, Eventually consistent.
"Databases in the Cloud: Elysian Fields or Briar Patch?" and "The NoSQL Alternative" have more information about transactional and non-transactional database solutions.
A second important difference is whether a DBMS offers simply meat-and-potatoes CRUD capabilities (Create, Retrieve, Update, Delete operations) or also has sophisticated query capabilities, such as aggregation, text searches and complex analytics. Related to this is whether the query capabilities are procedural or declarative (e.g. SQL). For those organizations adopting NoSQL databases, there are roll-your-own alternatives to capabilities built into SQL, such as scalar and table functions.
One might expect that using a NoSQL database means having no SQL capabilities, but a NoSQL database can be part of a SomeSQL application or service architecture.
APIs Re-hosting a database application in a private or public cloud can be a daunting proposition if the port also involves a NoSQL database. There is no industry standard for a NoSQL application programming interface (API), or for a cloud computing API. Eucalyptus and Amazon Web Services (AWS EC2) are the closest thing we have to a standard API for the cloud.
Instead of having to write all-new code for each platform, some organizations prefer a vendor-neutral API for cloud or database processing. It enables them to leverage existing code libraries, and even existing applications. There's been a pushback on the NoSQL phenomenon for those reasons, but there's more to the story.
The desire today for standard APIs is a reminder of what happened in the past when SQL became an important requirement for a variety of key-value and ISAM databases that had no SQL engine. Organizations had invested in client software that they wanted to be able to operate with data from a heterogeneous mix of desktop and server databases. The database driver emerged as the solution.
At Progress Software, John Goodson has been involved in developing data access specifications such as JDBC. As Senior Vice President of Enterprise Data and Business Solutions, John's customer base includes many organizations with databases for enterprise and web applications. He reports that Progress has customers seeking drivers for NoSQL databases because they need SQL and connectivity for ODBC- and JDBC-enabled applications.
Plus Ça change, plus c'est la même chose
Stay tuned for more about providing rich query capabilities with SQL and roll-your-own aggregation.One might expect that using a NoSQL database means having no SQL capabilities, but a NoSQL database can be part of a SomeSQL application or service architecture.

