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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 04 Jun 2006 15:46:16 +0200
Message-ID: <4482e39f$0$31650$e4fe514c_at_news.xs4all.nl>


Sasa wrote:
> mAsterdam wrote:

>> Sasa wrote:
>>> mAsterdam wrote:
[snip]

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

> No

Heh. I should have re-asked this question earlier.

A DBMS uses storage, and offers data-services to its clients. The clients do not have to worry about storage.

Except when a database runs out of storage, I think the issues of a DBMS seen as storage are completely irrelevant to any user or application interacting with it.

Actually this disagreement makes the rest of the conversaton chit-chat.

>> x Sharing data is not a consequence of persistence.
> No

Please try to clearly explain how it /is/, then.

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

It's not that far :-)

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

What /is/ it (beyond the part of schema the application needs)?

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

Queries not defined at design time.

>>> 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 :-( )

Ok. Disambiguation: It makes the end-user completely dependent etc.

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

Not in your design: It's just sets of persisted object-parts, not necessarily (directly) meaningful to the end-user.

> Where's the hole?

Organization of data, like organization of code, needs design.

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

"semi-independently" doesn't cut it.

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

Yes.
That is what makes it very hard to discuss any relevant design issues.

...

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

Ok for now.

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

>> ...
>>> What is the client in your language?
>>
>> Klant (Dutch ;-)

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

It has been much to long since I've been there. I'ld like to show my daughter Dubrovnik, Pula and Veli Losinj :-)

> ... It's just too difficult (to me) to be
> always concise and unambiguous.

Sigh... yes, for me to.

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

E.g. why infological complexities would be seqentail in nature. (BTW please start a new thread when you want to go into this.) Received on Sun Jun 04 2006 - 15:46:16 CEST

Original text of this message