Re: Mixing OO and DB

On 26 Mar, 15:42, Patrick May <p..._at_spe.com> wrote:
>      The implementation of this internal schema may change.  For a
> simple example, an array may be changed to a queue or a stack.  In
> this case the same data is being stored, but the behavior of the data
> structure is different.

You have made a change in the physical layer (inside the RDBMS). The interface (schema) to your application is still the same.

> A more complex example would be changing a
> data member to a computation or vice versa.

The schema is still the same. The application doesn't know if a relation is a base relation or a derived relation.

> In these scenarios, the
> application logic cannot be decoupled from the schema representation.

The application is coupled to the schema, but not to the schema implementation.

>      Now consider the same application modified to use a relational
> database.  The application logic continues to use the same data
> structures (stacks, queues, DAGs, etc.)

The basic idea with the relational model is that the application should only deal with relations as data structures. The application should not deal with stack or queues. The RDBMS is supposed to deal with that kind of structures in the physical layer. You might argue that flaws in current SQL databases forces you to still use that kind of structures and that might be true in some scenarios. But for a lot of applications out there, a SQL database does the job good enough.

> (we'll assume it's an OO application, since this is comp.object)

Actually it is cross-posted to comp.databases.therory as well.

> The implementation of the schema in the relational database presents a
> particular interface.  

Yes. The schema in a relational database is an interface. But it is NOT an implementation.

> This interface is based on relations.  Some
> form of mapping must take place to convert the data provided via that
> interface into the model used internally by the application.

Unless the application uses relations internally. If someone is using a SQL database and insists in performing the extra work to convert the data to another kind of structures (classes), one need to have some motivation for that extra work. If that kind of motivation doesn't exists, the mapping should not be done.

>      This mapping mechanism is exactly where the application
> implementation can be decoupled from the specific schema interface,
> typically through the use of something like the Dependency Inversion
> Principle.

The big question is why you need a mapping from one interface to another?

> > Structure is only one component of a data model.  An even more
> > important component is a set of constraints that specifies what
> > states and changes of state are possible.
>
>      Those constraints can be implemented in either the database or in
> the application.  

If the contraints could be implemented in the database, that must be preferred, to minimize the risk for data corruption.

//frebe Received on Thu Mar 27 2008 - 06:45:20 CET