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

Others have debunked a variety of areas in this post already but a few bits caught my eye ...

Robert Martin wrote:
> 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.
>

Applications come and go. Languages come and go. Character interfaces came and went. Client-server came and kind of went. Batch applications made a bit of a come-back in nice new clothes as web apps. And guess what ? The database is still there. Where would that suggest we expend our efforts ?

> 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.
>

Hmmmm .... (I can guess where this is going ...)

> 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.
>

Uh-huh ....

> ... 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.
>

Oh fabbo ! Let's take the data, throw it around a network a bit for processing, then throw it back around the network for storing it again ! Network bandwidth vendors must be rubbing their hands with glee at this sort of thinking. The biggest performance black hole in a networked application isn't the database, or the transaction log, or the PC client, or the disk drives - it's that gnarly chunk of wire running from the server to who knows where to wherever the client code is, and back again. The more goes through that chunk of wire, the slower things go. Better to leave the data exactly where it is for as much of the time as possible.

Incidentally, how do you write batch applications ? You know, those apps that deal with *lots* of data in one go ? Or do we only think about interactive, or pseudo-interactive, applications nowadays ?

> 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.
>

Integrity *must* be managed in the database. That way, any and every application that uses that data gets a consistent view. Not just "the" or "a" application - all of them. Including your shiny bespoke coded application but also the GUI report writer, the Excel spreadsheet with the ODBC link, the SQL terminal monitor session, and all the other routes to seeing the data application programmers have a wee tendency to forget about.

"Why are we seeing strange outputs on the reports ?" "It seems someone updated some data without going through the application, so we couldn't make sure they stuck to the rules." "!!!"

Always remember kiddies - it's a bit like puppies.

"Databases are for life - applications are for Christmas."

So far as I'm concerned, the best applications I've seen have put all the integrity, constraints, and heavy business logic in the database. The front end took care of basic validation of input and organising workflow. (And even then, because the front ends were in Java and the file format "chosen" was XML, there seemed to be a lot of, from the outside, unnecessary pushing and shoving going on out there.) But never mind - we can replace the front end with .Net, or whatever comes next - the important bits stay the same, tucked away in the database, oblivious to the fads and fashions outside. Received on Wed May 31 2006 - 20:44:06 CEST