Re: the relational model of data objects *and* program objects

erk wrote:

> mountain man wrote:

>> Central constraint enforcement should be in the database
>> and not in the traditional program objects, this is a "given".

>> Assume this practice is adhered to, what other relationships
>> exist between the relational model of the data and those
>> program objects which routinely manipulate this data?

What would this look like?

My kneejerk reaction is to say "no" to this argument because of the bletcherous implementations I've seen. The bad ones try to reproduce the db layer in upper layers, sometimes down to constraints, keys, etc. This should light the red lights because the db layer was built already and should not be built again. Two examples:

1. Any one-class-per-table implementation. Far too much work, much easier to have a library and a data dictionary. Methinks this easier solution is missed due mainly from the drive to reproduce db structures in code, but the great labor is seen as the "cost of doing business" because there is no other (agreed upon) conceptual model to follow.
2. Something like .Net's look-mom-a-complete-database-in-code, a heartbreaking work of staggering genius that was uncalled for because we already have a database layer and everything the .net layer does has to be checked again anyway.

So what does a relation look like when it respects the nature of a programming layer? The more we look at it here, the skinnier it gets. At the web layer it is an turnpike, taking POSTs and turning them into database INSERT/UPDATE/DELETE, then performing a SELECT and turning it into HTML. There is no implementation of "business rules" at all, unless you count some simple type-checking to avoid unnecessary trips to db server. Certainly no automation at that layer.

Am very interested in any other opinions.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)