Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout_at_myonline.be> said:

> Little point in preaching to the chuiar of course (how do you spell
> that damn word ?).
>
> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed.
>
> That said, application code is still highly important because it's
> needed to fill all the holes that current dbms's still leave wide open
> in the area of constraint enforcement.

This statement is fascinating. It takes the view that the majority of the system is DB and that application code simply fills the cracks. The DB represents the bricks and the application code is the mortar.

I disagree with this analogy. The RDBMS is a mechanisms for storing, accessing, reporting, data. That mechanism can be implemented many different ways and need not even be an RDB. The application code defines what the program does with the data.

Some RDBMSs have created an application language in which some application programs can be written. (stored procedures in SQL, or 4th gls, etc.) Typically these langauges are very special purpose and vendor specific. They are not general purpose application programming languages. Therefore, though they have their uses, they should be used with caution and restraint.

Even when such language exist, they are not part of the datbase itself.  They are still aplication languages.

The application code is not the glue that fills in the cracks. Instead the data is the cargo, and the application code is the railway network, engines, and cars, factories, that transform the raw data into useable product. The databases are the warehouses, and a specific vendor's DBMS is the material that the warehouse is made of.

Granted those warehouses are complicated structures with their own internal access and transport mechanisms to put the data in and get the data out, and keep the data safe. But they aren't the railway network, factories, and distribution networks.

>
> Little true story : some OO proponent in a seminar (well, it was
> actually "in front of an audience") declared that integrity enforcement
> is the responsibility of the application, blahblahblah (he also
> promoted meaningless ID's everywhere in the same breath). I asked him
> if he was actually aware that the first letter of the word IT stood for
> "information". His reply was : Yes, but the second stands for
> "technology".

The story may be true, but I'm not sure I get the point. Frankly, it IS the responsibility of the application to enforce integrity. Oh, the DB can enforce it while the data is in the warehouse, but the data comes out of the warehouse, gets transported all over the place, gets transformed in many different ways into many different products, gets presented to many different customers and put into many different systems, and for all these activities it is the APPLICATION that must enforce the integrity of the data. The DB loses control once the data is out of the warehouse.

Clearly keeping the integrity of the data in the warehouse is important. But that's not the whole story. It's not even most of the story.

Finally, and this is critical to the understaning of my point, the code in which data integrity is specified IS application code. It may be written in a special purpose DB language, or it may not. But it is code that supports the application.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |