Re: Databases as objects

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 21 Dec 2006 22:24:48 GMT
Message-ID: <QQDih.35948$cz.530403_at_ursa-nb00s0.nbnet.nb.ca>

Thomas Gagne wrote:

> Neo wrote:
>

>>> What I realized while trying to describe my preference to use DB 
>>> procedures as the primary (re: only) interface between my 
>>> applications and the database is because I believe my DB's physical 
>>> representation of data belongs to it alone and that customers of the 
>>> DB oughtn't be permitted to directly manipulate (change or query) its 
>>> data.
>>
>> Usually one prefers to use high-level interfaces. Below might be some
>> reasons one utilizes a lower-level interface:
>> 1) Impossible or impractical to do via high-level interface.
>> 2) Lack of performance.

>
> I agree programmers usually prefer higher-level interfaces.

Quite the contrary: You demonstrate exactly the opposite.

[meaningless commentary snipped]

> It is also a source of conflict between OO and Relational acolytes.

Actually, the source of conflict is the ubquitous (and frankly obstinate) ignorance among the OO crowd.

[more snippage]

> A database' model is static--it doesn't change for each of its
> consumers.

Here you model profound ignorance of data independence and logical independence in particular.

   An object model doesn't have to be static--it can change to
> be whatever is optimal for a specific task.

Good luck with that.

> Why don't we exploit that?

Because the rest of us are not as stupid as you are.

[boring anecdotes, straw men and various handwaving snipped]

> That which is impractical may also suffer performance problems, but
> performance alone isn't a reason to do anything (unless that performance
> is so poor as to make something unfeasible).

Whether performance alone is or is not reason depends entirely on your value proposition. If one's product has the word 'engine' in its description, performance very often is paramount.

   However, being able to
> improve performance in one place (like a procedure or view) is preferred
> to needing editing SQL sprinkled throughout an application or toolkit.

The solution to your problem is to avoid hiding your higher-level abstractions by sprinkling them in a mountain of generally useless lower level clutter in the first place. Received on Thu Dec 21 2006 - 23:24:48 CET