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

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


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.

[snip]

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

Yes.

> 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:
http://stein.cshl.org/software/boulder/docs/Boulder.html

> 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