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

mAsterdam wrote:
> Sasa wrote:
>

>> mAsterdam wrote:
>>
>>> Sasa wrote:
>>>
>>>> mAsterdam wrote:

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

It now seems more like a question of terminology. To me DBMS is the storage. Of course that client do not worry about actual implementation of that storage. I could say the same for flat file I/O though - the client doesn't have to worry about any OS specifics.

This is of course stretching it to far, obviously the database offers much more than for example fprintf/fscanf do.

However, I remain by the claim that DBMS is primarily a storage. As far as I know, everything in there revolves around persisted data. Whenever you issue an insert statement, the data persists (not taking temp tables and rollbacks into account). Whenever you select, you retrieve the persisted data.

> 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

Since the data is persisted it is readily available to any app if it has access to the persisted data.

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

To the outside (the app) it offers services for persisting objects required by the app.
 From the inside, it uses specific storage implementation to persist those object.

Other than that, it could provide services for retrieving the data by some criteria, depending on the needs of the application.

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

I'll stretch again - queries of DBMS are also defined at design time. During the design of that specific DBMS :-)

How often have you seen this requirement? Was the requirement that absolutely every possible query supported by underlying storage is allowed (and not some meaningful subset)? How was it implemented? By simply allowing a user to enter the SQL queries in plain text? If yes, what sort of users were those?
I would sure like to have my entire user base consisting of people who are good in writing SQL statements.

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

Yes, but in my experience the requirement is not "allow user to make all possible queries". It usually comes down to - "typically, users need to query this data over that criteria". This then makes the user dependent on the queries the user wanted.

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

What makes you think that? The data in the database describes whatever must be persisted (most of it really being pure domain data, and some probably to support non domain stuff). But not in the sense of objects, but rather in the sense of data.

>> Where's the hole?

And in RDBMS it most certainly gets one - the design of normalized structure.

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

Well the two are used to solve the same business problem, so if nothing else, they are tied with that fact. Then of course, in my view DBMS is there to support the application, not to be the application.

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

Why?
If it's not too time consuming, you could provide some simplified rough overview or example of what you think is good design/architecture.

> ...
>

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

>>> ...
>>>
>>>> What is the client in your language?
>>>
>>>
>>> Klant (Dutch ;-)
>>
>>
>> Klijent (Croatian :-) ), but that was not what I asked you.

The mail is valid, so if you pass by let me know. Maybe we can still have that beer :-)

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

I'll leave it as it is for now.

Sasa Received on Sun Jun 04 2006 - 19:40:26 CEST