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

From: Sasa <sasa555_at_gmail.com>
Date: Sat, 03 Jun 2006 23:56:05 +0200
Message-ID: <e5t0h9$jrj$1_at_sunce.iskon.hr>


mAsterdam wrote:
> 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.

Sorry.

> Do you agree that
> x A DBMS is not storage.

No

> x Sharing data is not a consequence of persistence.

No

> x Interpretation problems with sharing data
> via bytes in files do not hold for RDBMS.

Partially, but really don't find it relevant.

> x the (logical part of) the schema is
> part of the software design.

Yes.

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

For what it's worth, I like discussing this with you - you are an empathic collaborator (as opposed to some others here in the thread). It would probably be better to talk this over a couple of beers, sadly I don't think it's feasible :-(

>

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

Be my guest.

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

I lost you there, but somehow I don't think the subtopic is relevant.

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

The layer has a specific knowledge - how to persist OO representation into a specific persistence implementation. You design it taken specific needs into account.

> ...
>

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

Depends on what you really mean by ad hoc queries.

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

Sorry, the user here meant the OOL code (here the client/user problem in my dictionary rises again :-( )

> ...
>

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

I don't see how not? It is the very specific data having its own nature. Where's the hole?

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

No. They should be designed semi-independently of the object persistence layer. The client (app(s)) dictates what it wants. The DBMS chooses how will it present it. The mapper, simply translates.

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

I see them more as a properties or features (albeit important ones) of persistence implementation.

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

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

Thanks for the tip :-)

>> 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 think we agree more than it seems at a first glance, but it's still a notion I can't argument.

As already said, I regard sharing, concurrency and other benefits of RDBMS as a properties of specific persistence implementation (RDBMS in this case). Don't get me wrong, these are not irrelevant or secondary issues. However, they are a factor which affect choosing one or another implementation (I refer back to my previous two examples loan vs. simple address book).

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

Acknowledged.

> ...
>

>> What is the client in your language?

>
>
> Klant (Dutch ;-)

Klijent (Croatian :-) ), but that was not what I asked you.

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

And I understand them as well :-) It's just too difficult (to me) to be always concise and unambiguous.

> ...
>

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

Such as?

Sasa Received on Sat Jun 03 2006 - 23:56:05 CEST

Original text of this message