In the big open world of the cloud, highlyavailable distributed objects will rule.By eRiK meiJeRall yourDatabaseare Belongto us

iN The DaTaBaSe world, the raw physical data model
is at the center of the universe, and queries freely
assume intimate details of the data representation
(indexes, statistics, metadata). This closed-world
assumption and the resulting lack of abstraction have
the pleasant effect of allowing the data to outlive the
application. on the other hand, this makes it difficult
to evolve the underlying model independently from
the queries over the model.

As the move to the cloud puts pressure on the
closed-world assumption of the database, exposing
naked data and relying on declarative magic becomes
a liability rather than an asset. In the cloud, the roles
are reversed, and objects should hide their private
data representation, exposing it only via well-defined
behavioral interfaces.

The programming-language world
has always embraced such an open-world assumption by putting behavior at the center of the universe and
imperatively building reliable applications from unreliable parts. Object
databases are back with a vengeance.
To help developers transition to the
cloud, the existing class libraries and
tool infrastructure must evolve to run
as highly available services exposed
using regular object-oriented programming language interfaces that
reflect the relevant operational details.

Database developers (let’s call
them modelers) and application developers (let’s call them programmers)
have dual views of the world. If you
are a modeler, then everything revolves around data—and data about
that data (metadata). The world of database models is noun-based, talking
about Customers, Orders, LineItems, among others. Once modelers
have designed the data model correctly, they consider their job done.

In the realm of modelers, there
is no notion of data abstraction that
separates abstract properties of the
model from the concrete details of
the fully normalized realization in
terms of tables with PK/FK (
primary-key/foreign-key) relationships (see
Figure 1).

The outside-in aspect of PK/FK
relationships actually amplifies the
need for exposing all the details of the
underlying rows and tables. For example, you cannot pick up one specific
customer row from the Customers
table and ask it what its list of orders
is. Instead you must have access to
and understand the schemas of both
the Customers and Orders table
to perform a join across all the order
rows in the Orders table and all the
rows in the Customers table to check
if the foreign key in the order matches
the primary key of the customer, and
then filter by your target customer.

Modelers consider this lack of data
hiding an advantage since it allows
for ad hoc queries on the data that