Sandeep wrote:
> Thanks for your post. All the scenarios you have mentioned are valid
> and in fact there will be many more scenarios depending on different
> situations. Enterprises will make their decisions based on many
> factors.
>
> Here is one article
http://www.eweek.com/c/a/Database/Cloud-Database-Adoption-Proceeds-Slowly-Analysts-Say-352596/.
>
> At fundamental level we believe that model of "traditional (i.e.,
> relational, SQL) processing using a cloud platform" is going to be
> most viable for enterprises. But what we think is that customer should
> have complete freedom of using the underlying cloud platform when
> using this model. We also think that customer should also have
> complete freedom of choosing between traditional RDBMS and cloud
> platform without affecting their applications. That's what we are
> trying to achieve at Cloud2db. That's our business case.
>
>
>
While it it's certainly possible to put a layer that offers a degree of
common semantics against a variety of database systems, I don't think it
can, in fact, hide the differences between the systems. Let me explain.
All database systems have to handle not only data, but relationships
between pieces of data. For example, a personnel database has to handle
not only information about individuals, but also about the relationship
of individuals such as "person A reports to person B". How these
relationships are handled within a specific database system is what we
mean by data model. In an object oriented databases, the links are
explicit -- pointers or an analog of points. In a relational system,
the link are presented by common values. In a single table database,
the relationships are internal to a complex row.
To maintain relationships, some sort of concurrency/atomicity control is
required. In object databases, concurrency and atomicity are
application problems. In relational database systems, concurrency and
atomicity are handled automatically by formal transactions. In single
table databases, there are no relationships outside of a single row, a
transaction is a single row update.
In all cases, the data manipulation language (DML) is necessarily tied
to the data model. Object databases require a low level object to
object navigational language. Relational databases use a high level,
multi-row, multi-state DML, letting the transaction manager keep
everything straight under the covers. In a single table database, there
really isn't any concurrency control other than the atomicity of a
single row update, so it doesn't really matter.
Sure, you can put a SQL (or any other DML) layer on top of anything, and
to a large degree hide the differences. But it isn't possible to hide
the differences between data and concurrency models. You can do all
sorts of SQL operations on BigTable or SimpleDB, but, unlike a
relational system, there is nothing there to guarantee the integrity of
the relationship between data.
An application layered on SimpleDB or BigTable must be designed around
the features and constraints of SimpleDB or BigTable. An application
designed for a relational system, on the other hand, is designed with
the implicit understanding that a transaction manager is going to manage
record relationships. If you move that application to a system without
a transaction manager, it's going to run, but it isn't going to work
(meaning, specifically, preserving database consistency in the face of
concurrent updates).
So I understand completely how you can build a superficial SQL layer on
relational and non-relational systems, but since the concurrency and
consistency semantics are so different, I don't see what it buys you.