Re: The Practical Benefits of the Relational Model

In article <kdPb9.19157$g9.59298_at_newsfeeds.bigpond.com>, mountain man <prfbrown_at_magna.com.au> wrote:
>"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message
>news:3d6f5561$1_at_news.uia.ac.be...
>> In article <j%yb9.18405$g9.57408_at_newsfeeds.bigpond.com>,
>> mountain man <prfbrown_at_magna.com.au> wrote:
>> >
>> >2) I do not disagree. In fact it is my observation not from theory but
>> >from the production floor that has convinced me that "IN THEORY" there
>> >is nothing that cannot be expressed by the SQL at the RDBMS level.
>>
>> Do you mean that SQL can express all queries? That's not true, it may
>> often be in practice, but certainly not in theory; SQL is not
>> computationally complete.
>
>Can you provide me with an example of computation exemplifying the
>(theoretical) incompleteness of SQL?

Sure, try saying "there are no cycles in this binary relation" in one SQL statement.

>> Or do you mean that with SQL you can express all database
>> constraints? That's also not true. Roughly speaking it only covers
>> first-order logic.
>
>While that may be, armed with SQL code, some R&D and an RDBMS scheduled
>task queue I can enforce all constraints without exception whatever they
>may be.

Interesting. How would you tackle the no-cycles constraint?

>> >In practice however, one invariably finds that the bulk of this
>> >OI/BR/etc is in fact resident in the applications code and NOT in the
>> >RDBMS. This was my point.
>>
>> Yes, but (1) you still haven't explained exactly what you mean with
>> "OI/BR/etc"
>
>Organisational Intelligence/Business Rules/etc The guts of the specific
>database application software code that the organisation or business
>happens to use.

Is that the best definition you can come up with? "The guts of the database application"? That's not very informative I'm afraid and I happen to believe you can do better than that.

>> Are the constraint languages not powerful enough? Is it not efficient
>> enough? Are the application designer not able to formulate the database
>> constraints in some formal logic? Or what?
>
>When any contemporary database application software system environment is
>loaded on top of an RDBMS, which has already been loaded on top of an
>Operating System Software environment, the total number of software systems
>environments is 3.

Sure. And how exactly does that answer my question?

>Using current program development tools and methodologies application
>developers do not use the RDBMS exclusively to code constraints and rules
>and often maintain these in the Apps environment code.

Yes, I already agreed with that. The question was if you had an explanarion for why this is so.

>Ideally, according to CJ Date, this situation should be resolvable in the
>general sense such that all the logic contained in the APPS environment
>(ie: OI/BR/etc) might be represented entirely within the RDBMS. Somehow.
>But how is this to happen?

Again, wy doesn't it happen already? Before you can come up with a solution you have to understand this first.

>The problem is to migrate the code (usually written by application vendors)
>representing the BR out of the application code and into the RDBMS by some
>means. Does this make any sense to you on the other side of the Pacific?

The Pacific? I think you are looking in the wrong direction. :-)

• Jan Hidders