Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 02 Jun 2006 22:56:17 GMT
Message-ID: <lm3gg.16688$A26.385214@ursa-nb00s0.nbnet.nb.ca>


Sasa wrote:

> Marshall wrote:
>

>> There is a fundamental, foundational concept to grasp here,
>> that is easily obscured by the excessive verbiage. But
>> unless you get this foundational point, you won't be able
>> to follow the arguments of the c.d.t. people at all. So I'll
>> simply present it in isolation.
>>
>>   A DBMS is not "storage." A DBMS is a system that manages
>>   data, where "manages" describes a whole host of high level
>>   facilities.

>
> So can you list some short but specific keypoints - what are these
> facilities?

Start with entering, manipulating, reporting and deriving data. Add security. Concurrency. Correctness. Adaptability. Logical and physical independence. Recovery. That should be good enough for a start.

The dbms uses some sort of logical data model to provide a formalism including structure(s) and operations for achieving instantiation, manipulation, correctness, derivation, logical independence etc. The other facilities, such as security, will also use the formalism for reference.

A relational dbms uses the relational model which defines a single structure, the relation, and operations on relations equivalent to the relational algebra and the relational calculus, which are essentially set algebra and predicate calculus.

The specific formalism provided by the relational model, being equivalent to predicate calculus, allows one to describe a constraint as a well-formed formula for instance.

The other formalisms currently available to us are based on graphs. As such they are more complex models with additional structions and do not provide comparably powerful operations. Due to their increased complexity and reduced facility, these other formalism have proved inferior to the relational model.

>> The c.o. people's arguments are mostly based on the false
>> premise that a DBMS is a kind of storage mechanism.
>> Once you accept a false premise, you can prove anything.

>
> I am very far from being DBMS expert, so I offer following statement,
> fully aware of my ignorance. While I regard DBMS primarily as a storage,
> I also use it to perform rich queries (which obviously cannot be
> performed as easily in for example flat file), enforce integrity and
> security.
>
> The features listed are still very related to the "storage" as I see it
> from my little OO world, so I refer to my first question, what is that
> host of high level facilities?

So, what you are saying is you have a prejudice and you have difficulty shaking that prejudice. Security and integrity are high-level facilities that I doubt you really use all that effectively given your prejudice.

But the highest level facility is the formalism itself.

>>> The point (as I see it) is that just as client code can vary storages,
>>> storage can serve different clients.
>>
>> Now we see that this statement, while it may have some
>> value is certain contexts, does not apply when we are
>> discussing DBMSs. Hence it is neither true nor false
>> relative to the current discussion; it is simply talking
>> about something else.

>
> I could agree, providing that the already mentioned "host of high level
> services" includes something dramatic which would force me to move my
> domain logic (combined data and behavior) to SQL.

Is predicate logic a high enough level service for you to consider expressing logic in it?

> In my statement, I was trying to accentuate the need for loose coupling
> between client and DBMS.

What makes you think the dbms cannot extend into what you call the client?

> Given the fact the DBMS can serve more apps (but actually even one can
> mean trouble if SQL code is spread around the app code)

You have done nothing at all to substantiate the parenthetical comment. You are asking us to accept it axiomatically, and we have already indicated we do not.

, and given the
> fact that one app might want to switch DBMSes

Why is that a fact? Do you also expect the app might want to switch logical data models? Do you also expect the app might decide to re-invent large parts of a data management system (however poorly) so it can use flat files?

  I think it would be smart
> to decouple both as much as possible, which to me means no client code
> in DBMS, and very localized DBMS specific statements in client code.

Define client code.

This 'client code' to which you refer. What does it do that is not entering, manipulating, reporting or deriving data? Of that which remains, what does not interface with the external world through some device or another?

  Now
> I'm interested with what part you DBMS guys (no irony, or offense meant)
> disagree and how do you envision it?

Marshall already explained that we disagree with your axiom that data management is merely storage because the axiom is in fact false. Everything you derive from that axiom is pointless. Received on Fri Jun 02 2006 - 17:56:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US