Re: Mixing OO and DB

"Thomas Gagne" <tgagne_at_wide-open-west.com> wrote in message news:pLGdnTuiAYVjmFHanZ2dnUVZ_q2hnZ2d_at_wideopenwest.com...
> Marshall wrote:
>> <snip>
>> I invite anyone who thinks it is possible to decouple application
>> code and database schema to show me how to make good
>> use of a general ledger/accounts receivable database schema
>> in building a content management system.
>>
>
> That would be easy. The database's design should be independent from
> the application programming language. If it's independent then it can
> support multiple languages and paradigms.
>

If you're going to drill a hole, you can use a DeWalt, or a Milwaukee, or a Black and Decker power drill, or you can use a hand drill, but the tool used has little if anything to do with the size or depth of the hole.

In the same way, if you're going to build an application, you can use C++ or Java or VB, or you can use assembler, but the application programming language used has little if anything to do with the database schema.

> A database's design can and should improve independently from
> applications. When that isn't the case then improvements to the
> database must be delayed as changes are coordinated with all
> dependents. Of course the problem with coordinating with dependents is
> being able to find all dependents.
>

Improvements to the database should have little if any impact on applications. Only destructive changes, such as deleting or changing a column or a table, should impact applications, and I wouldn't consider destructive changes to be improvements.

> The same mechanisms that provide independence between systems and
> modules, an interface, can be employed between databases and their
> applications. In fact, considering the costs of coordination an
> argument could be made that a language-independent interface must exist
> to avoid delayed and overly-complicated releases.
>

This is insane. Or perhaps it is an example of conflating a database implementation with a database specification (schema). Yes, there are many RDBMS implementations, and each has its own idiosyncracies. It can be a good thing to isolate code that is specific to a particular implementation and perhaps to build an interface to make it possible to switch RDBMS implementations without recompiling application code, but that doesn't mean that the database /schema/ should in any way be hidden or encapsulated. The schema is a specification and must be an integral part of the specification of the application. How can you possibly build code to manipulate something if you don't know what that something is.

> All attempts by applications to access a DB's tables and columns
> directly violates design principles that guard against close-coupling.
> This is a basic design tenet for OO. Violating it when jumping from OO
> to RDB is, I think, the source of problem that are collectively and
> popularly referred to as the object-relational impedance mismatch.
>

I think the impedance mismatch is due to sloppy thinking. The whole point of an application is to manipulate information. The whole point of a database is to store information so that it can be manipulated. What is common to both is that which specifies what information can be manipulated: what is common to both is the database schema.

> --
> Visit <http://blogs.instreamco.com/anything.php> to read
> my rants on technology and the finance industry. Visit
> <http://tggagne.blogspot.com/> for politics, society and culture.
Received on Tue Mar 04 2008 - 02:04:52 CET