Re: Database type independence

From: Calum Grant (invalid_at_see.sig)
Date: 09/01/04 

Date: Wed, 01 Sep 2004 21:24:20 GMT

Fredrik Bertilsson wrote:
> Many OO evengalists argue very hard for making the persistance layer
> independent of the database type (RDB, OODB, LDAP, etc). They want to
> be able to change the database from a RDB to an OODB without changing
> the business logic.

I don't think you necessarily need an OODB - but you do need to have a
good interface between a RDB and an OOPL. Embedding SQL statements
hap-hazardly throughout the code, and using proprietary interfaces (such
as MySQL's C interface) is not good for maintainability.

My feeling is that a RDB is just about as complicated as you should get
- the OO stuff can be performed at the language level, and not at the DB
level.

> But the cost for doing this is very high. The developer is forced to
> implement (or configure) an extra transformation/mapping layer. The
> persistance frameworks becomes unnecessary complex. This requirement
> about database type independance is one of the main reasons that EJB
> is so very complex. Besides, data-aware components are not possible to
> use because of this requirement.
>
> My question is, is it really worth the cost to make the architecture
> independant of database type. On the software market, there are a huge
> demand for relational database vendor independant applications. Most
> customers want to be able to run the applications they buy on their
> favorite dbms system like Oracle, SQL Server, MySQL etc. But how many
> customers want the application to be able to run on their OODB? I have
> never heard about it anyway.

ODBC is one such abstraction layer. But I feel that these abstraction
layers (and heaven forbid, a C interface to a DB) are too low level.
There is stuff like ADO that does perform a data-binding to C++ objects.
  Therefore, the cost of writing an abstraction layer is nil - it has
been written already.

One can also make use of views and stored procedures - thereby
presenting a consistent interface to the application even though the DB
structure and vendor changes.

> Relational databases have proven to be the superior database type.
> They have almost 100% percent market share and this fact does not seem
> to change in the near future. In fact relational databases is more
> likely to live longer than most programming languages used today
> (Java, C#, C++, PHP, VB etc). There have been numerous examples of
> applications changing programming languages (from Cobol and Fortran to
> Java or VB/C#) and the database remains the same. But the examples of
> changing database type and keeping the application the same is
> extremely few.

I would urge a decoupling of the DB and the application because it
improves maintainability. By restricting access to the DB through a
fixed set of points, optimizing SQL queries and access patterns is
obvious, the number of DB connections is low, and the transactional and
locking behaviour of the queries is easier to analyse. Allowing
free-reign of an application to a DB is asking for anarchy.

> Is it really reasonable to invest money in a feature (database type
> independence) that in almost no cases are needed? I think that if IT
> managers really knew that when they are investing in mainstream OO
> architecture, they are also spending money on things they will never
> need, they would make different decisions.
>
> It would be interesting if it is someone out there that actually uses
> something else but relational databases for persistance? And in that
> case, what type of applications and what database vendor. It would be
> even more interesting to know if someone actually have changed from
> relational database to OO database (or something else), whithout
> having to rewrite the business logic.

Here's an odd-ball package I wrote. It stores C++ objects in a
memory-mapped file. It has the performance of memory, and the
persistence of a database. http://visula.org/persist. It's fun, but no
way near safe enough for most DB applications.

Calum

Relevant Pages

  • Re: Looking for a decent data access architecture to implement
    ... > application so that there is a clean separation between the data access ... > layer, the business layer and the GUI layer. ... > the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Looking for a decent data access architecture to implement
    ... application so that there is a clean separation between the data access ... layer, the business layer and the GUI layer. ... the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Size matters to some
    ... The underlying remote database connection ... physical layer is actually managing it all, the logical layer is forced to ... constraints as specified by developers. ... want to validate the information getting written. ...
    (comp.databases.pick)
  • Re: OO vs. RDB challenge
    ... > Layer 1. ... If you filter your data after you retrieve it, ... possible to redesign the database schema to enable SQL to do its job. ... A good RDBMS could integrate an external authentication server. ...
    (comp.object)