Re: data management

From: Sasa <sasa555_at_gmail.com>
Date: Mon, 05 Jun 2006 19:59:48 +0200
Message-ID: <e61re5$q0c$1_at_sunce.iskon.hr>

mAsterdam wrote:
> Sasa wrote:
>

>> mAsterdam wrote:
>>
>>> Sasa wrote:
>>>
>>>> mAsterdam wrote:
>>>>
>>>>> Sasa wrote:
>>>>>
>>>>>> mAsterdam wrote:
>>>>>
>>>>> ...Do you agree that a DBMS is not storage.
>>>>
>>>>
>>>> No
>>>
>>>
>>> A DBMS uses storage, and offers data-services to
>>> its clients. The clients do not have to worry
>>> about storage.
>>
>>
>> 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.

>
>
> One of the attractions - to me at least - of OO is the promise
> of having the right tool do the job. It is a way to get there.
>
> For storage/persistence you can't outperform a local file.
> So use it.

Not sure I follow what you mean to say here.

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

>
>
>
>
>
>

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

>
>
> No. It is only available as it is meant to apps that
> have access to the exact same persistence mechanism.

I'm kind of lost as to why are we discussing this. Doesn't same hold for the RDBMS? If my data is in the SQL, each application accessing the database must have access to the exact same persistence mechanism (the exact SQL dialect and the structure of the data).

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

>
>
> Why build what you already could have?

Where am I doing that?

> ...
>

>>>>>>> How do you provide the users with ad hoc query facilities?
>>>
>>> Queries not defined at design time.
>>
>>
>> I'll stretch again - queries of DBMS are also defined at design time. 
>> During the design of that specific DBMS :-)

>
>
> You meant the design of the schema, right?

No, but the design of the DBMS application itself.

Whatever API the system offers you is what you have at your disposal. What if DBMS allows that where clause only filters on primary keys, and in turn returns at most one row? To what do "queries not defined at design time" amount to?

>> How often have you seen this requirement? 

>
>
> Many times.

Fair enough - I simply didn't have that case, but my experience is most probably far more limited than yours.

>> Was the requirement that absolutely every possible query  supported by 
>> underlying storage is allowed (and not some meaningful subset)? 

>
>
> No, just the meaningful subset: data.

But not the subset of the data?

>> How was it implemented?  

>
>
> By means of query tools such as Business Objects/Crystal reports,
> and Discoverer or by programmers (as in not end-users) using SQL
> directly.
>

>> By simply allowing a user to enter the SQL queries in plain text?

>
>
> No.
>

>> If yes, what sort of users were those?

>
>
> Programmers and trained assistants to the end-users.
>

>> I would sure like to have my entire user base consisting of people who 
>> are good in writing SQL statements.

>
>
> Heh.
>

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

>
>
> YMMV
Agreed.

>>>>>>> Queries give user meaningful data (or information if you
>>>>>>> care to define etc.) as results, not objects.

>
>

>>>> 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.
>>
>>
>> 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?
>>>
>>>
>>> Organization of data, like organization of code, needs design.
>>
>>
>> And in RDBMS it most certainly gets one - the design of normalized 
>> structure.

>
>
> Now you have a normalized structure of pieces of object-corpses -
> still no meaningful data outside the context of the object.

What do you mean by object corpses? Do you think that I consider the data object driven?

>

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

>
>
> In my view the DBMS is there to organize the data,
> the application is there to support proces, including
> but not limited to data-capture and data-rendering.
> OO is there to organize the application code.

What is precisely the application in your view? The code lying on top of the DBMS?

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

>
>
> Something like this: make sure to use the right tool
> for the job at hand.

:-)

> Beyond that (I think I already said that) IBM
> abandoned the SAA (Standard Application Architecture)
> initiative because it was to complex a mission.

You said it already. I didn't ask you to defined a standard general rule. I asked you to provide example. Can you construct simple example where the database does qualify as more than storage, and provide some argumentation why?

I'm aware that it might be time consuming, so I don't mind if you choose not to do it.

Sasa Received on Mon Jun 05 2006 - 19:59:48 CEST