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

From: mAsterdam <>
Date: Sat, 03 Jun 2006 23:15:28 +0200
Message-ID: <4481fb94$0$31651$>

Sasa wrote:
> mAsterdam wrote:
> [snip]
> I've purposely avoided continuing the first part of discussion, as it
> seems to me it doesn't lead to something essential or constructive
> anymore and this posts are getting fairly long.

It leaves the most basic issues unresolved.

Do you agree that

   x A DBMS is not storage.
   x Sharing data is not a consequence of persistence.    x Interpretation problems with sharing data

      via bytes in files do not hold for RDBMS.    x the (logical part of) the schema is

      part of the software design.

> ( Update: it took me almost an hour to write the post :-( this is
> getting to be exhausting and time consuming)

I sympathize with that - and the posts are getting way to long, agreed.

> If you think I've avoided something relevant, feel free to introduce it
> back to the discussion.

Leaving out foundations leaves nothing much to build on, does it.

I'll call sir snip-a-lot.


> Do I understand correctly that "common reference" signifies that what
> two system have in common?


> Only if a object is stored as a pure byte after byte image?

This should be irrelevant at the level of design, no? But you'ld have to design it if you go that way.

> If you write your isolated mini persistence API with general services,
> and then a layer on top of it which knows how to persist instances of
> specific classes using that API, the common reference is entirely
> represented in the layer.

What is it that this layer must have in common with the database? IMO it is (a part of) the schema. How do you design it?


>> How do you provide the users with ad hoc query facilities?

> Where I had to do this, the 'ad hoc' query feature amounted to
> combinations of simple filters (which would map to the WHERE part of the
> query). When multiple filters were used in most cases only logical and
> was supported. The set of attributes available in filtering was
> predefined. There was no relational filtering (e.g. give me all orders
> for customers which satisfy...)
> That was more than enough for the end users.

Short answer: you don't. Why so many words? I should have put 'How' in my question between parentheses.

> Having these prerequisites in mind, the internal representation of the
> filter would be made in dedicated classes, representation of its
> combination would be the collection of instances of such classes, with
> the isolation layer translating this into implementation specific (e.g.
> parts of the select statement).
> This then makes the user independent of the specific on how the data is
> searched.

On the contrary: It makes the user completely dependent on the few queries the application implementor designates important enough to build a wrapper for.


>> Queries give user meaningful data (or information if you
>> care to define etc.) as results, not objects.
>> How then is querying data related to objects, or more specifically 
>> object-persistence? (m.m. security, reliability).

> To expand my statement. Since I use the DBMS primary for persistence
> services, then
> 1. Querying the DBMS means querying the persisted data.

How can the data have any meaning by itself if it's just the storage for persistence you are querying? ISTM there is a serious hole in you design approach.

> 2. Security features of the DBMS relate to the persisted data.
> 3. Reliability applies to the persisted data.
> What is in my database is then the data, and there are no notion of
> objects there.

And all tables, columns and constraints in your schema were designed and named by the object-persistence layer designers/programmers, for programs.

>> Could you give an example where a DBMS purely for persistence
>> is /not/ gross overkill?

> Banking loan application serving couple of hundred clients
> simultaneously, processing couple of hundred thousands pieces of
> information (client, loans etc.)

I see two requirements /beyond/ (as opposed to /purely/) persistence here: data sharing and concurrency.

> The extreme counter example could be simple address book tuned for only
> couple of dozens of entries, each entry containing only few attributes
> (e.g. name, last name, address and phone) which is designed to be used
> as a single user desktop application. I could imagine using XML for such
> app.

You surely mean this as an example where a DBMS purely for persistence /would/ be gross overkill, right?
Aside: Even XML is seriously bloated for this app. A simple boulder will do nicely:

> I suspect this will not shed the light, though. It would be more
> interesting to see the cases where it is not so clear whether to use
> simple files or relational database as a storage.
> Could you provide your own examples?

My position is that DBMS are not for persistence. You are asking me look for a counterexample. I tried. I can't.

Your (and others') position is that you
use DBMS for persistence.

My take on that position is that people who say that have implicit requirements /beyond/ pure persistence. So I challenged you to come up with an example where a DBMS purely for persistence is /not/ gross overkill. Hopefully your or somebody else's answer will refute my position/take or expose some of the additional requirements.

Right now we have sharing and concurrency.

I tried. I can't. Can you?

If you can't, will you accept that it is not (just) persistence what you are looking for in a DBMS?

I'll skim the rest (constraints!) for now. Maybe later I'll go into it. It just to much for one post.


> What is the client in your language?

Klant (Dutch ;-)

> I use the term for everything which is being served by something else.
> E.g. if function a uses function b then a is the client and b is the
> server. The end user is the client of the app etc.
> This is probably to broad of a usage, sometimes my coworkers don't
> understand me (especially when I use server for something that doesn't
> represent web or database server).

Ok this one: I'll understand you if you use it this way. (But I also understand your coworkers sometimes forget that you use it this way).


>> I will not go into the sequential/non sequential nature
>> of infological complexities here. This post is already way
>> to long. Maybe later. Maybe in another thread.

> As you please. I'm sorry though, as this is in my view one of the more
> important reasons why I prefer OOL to RDBMS for domain logic. I would be
> very glad to hear some oppinion from the "opposite camp" (don't take
> this term to seriously).

Well, I'm not the only one reading this - but I'm sure you would have to give something more to go on. Received on Sat Jun 03 2006 - 23:15:28 CEST

Original text of this message