data management (was: The wisdom of the object mentors)

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 04 Jun 2006 23:34:24 +0200
Message-ID: <44835194$0$31644$e4fe514c@news.xs4all.nl>

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.

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

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

...

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

> How often have you seen this requirement?

Many times.

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

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

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

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

>>>> My position is that DBMS are not for persistence.
>> It has been much to long since I've been there.
>> I'ld like to show my daughter Dubrovnik, Pula and Veli Losinj :-)

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

Mine to. If you ever get to Amsterdam you are welcome. Received on Sun Jun 04 2006 - 16:34:24 CDT