Re: The Practical Benefits of the Relational Model

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3d6fd524$1_at_news.uia.ac.be...
> 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?

>

More information please on the quoted phrase. And why the restriction about one SQL statement? Incomplete means incomplete, does it not?. Whether one or one thoud\sand and one?

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

Slowly, after you tell me exactly what it represents, or possibly point me at some online documentation.

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

Let us assume that we have database application software product running at some organisation using some RDBMS. It has client side code and server side code (stored procs, etc)

If you were to examine the set of code from the Application and add to it that set of server side code, supplied by the vendor of the application, and add that to that the code which is supplied by the RDBMS vendor, then in that (union) set of code is defined whatever "capturable intelligence" that organisation has at this time invested in computer systems.

It sounds as if there is some "theoretical definition"? If you know it, consider letting me know.

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

Sequentially? Humor aside, I'd expect it to answer your question on the basis that the environment is not a single RDBMS but rather an interaction of 3 environment. Database theory seems to apply to the internal realms of an RDBMS, although I could be off base.

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

Well, historical reason and reasons of profit, trade and commerce often mixes that which is theorietical with that which is merely commercial.

Take your standard Application Package vendor for the RDBMS environment. Why should this vendor release control of the code held in the program object code (applications software) layer, and migrate it into the RDBMS? If there were some form of reasons for doing this, or not doing this, what would these reasons be?

I have no explanation for the history of things. Do you?

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

Well this seems like a very important juncture. If you could exlain yourself, I'd be grateful.

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

A philosophical conclude? :-)

East and west ... it all resolves to the sphere of earth, covered by a layer of water and a layer of air that is interpenetrated by the electromagnetic energy of sunshine.

So where on the planetary surface are you? Belgium? So we would need to skip over the land mass between the Pacific and the Atlantic as well....

Farmer Brown
Falls Creek,
Australia
' Received on Sat Aug 31 2002 - 05:44:02 CEST