Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 1 Jun 2006 21:25:20 -0500
Message-ID: <2006060121252058821-unclebob_at_objectmentorcom>
On 2006-05-31 13:44:06 -0500, "Tony D" <tonyisyourpal_at_netscape.net> said:
> 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 ?
On the domain that is changing, since that's where the "progress" is being made. I presume that you are glad that character interfaces were replaced.
The point is that the majority of our effort is NOT spent on the database because the database does not do the majority of what needs to be done.
>> ... 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.
Did I use the term "Network"? I was referring to the movement and transformation of data in a system. That system might be distributed, or wholly contained within a single processor.
> 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.
I quite agree. Which is one reason that I question the ubiquitous use of database servers. Not that they aren't useful; of course they are. It's just that few people seem to question whether or not they should be used on a case by case basis.
But I don't know how we got on this topic, since the topic of the original post was a question of application design structure. Towit: Do you agree that the design of an application program should be strongly decoupled from the DBMS, to the extent that the DBMS could be swaped out for a completely different technology.
> 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 ?
FOREVER {
READ
PROCESS
WRITE
}
>> 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.
Agreed. But when the data is moving around the system, it is the application that keeps it intact.
> That way, any and every
> application that uses that data gets a consistent view.
Agreed. However, the applications must keep the data sane as they manipulate it.
> Not just "the"
> or "a" application - all of them.
Agreed.
> 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.
Agreed. Believe me. Agreed. I have a team at the moment that is replacing a suite of applications that were written by unskilled people in a hurry, and that caused terrible problems of database corruption that had to be manually repaired on a daily basis. So I know.
> "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."
> "!!!"
In our case, of course, the corruption took place WITHIN the applications. The database (Oracle) simply accumluated more and more cruft.
> Always remember kiddies - it's a bit like puppies.
> "Databases are for life - applications are for Christmas."
Cute. Christmas seems to be coming very frequently nowadays, and boy do we pay a lot for those presents!
> 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.
Yeah, that's how he wrote it. A shame too. I'm sure you could have done better. But we've redone it using .Net. Of course we've maintained a lot of the integrity checks in the DB. But we've moved a lot of the business rules into the C# code so that we can test with automated unit tests.
-- 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 |Received on Fri Jun 02 2006 - 04:25:20 CEST