Re: data management
Date: Tue, 06 Jun 2006 00:03:02 +0200
Message-ID: <4484a9c6$0$31639$e4fe514c_at_news.xs4all.nl>
Sasa wrote:
> mAsterdam wrote:
>> 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.
Don't use anything less than the best tool for the job if all you need is what the cheapest tool is best at.
>>>> ... makes the rest of the conversaton chit-chat.
Maybe we can continue this off-line.
I don't think our dialogue is interesting to most of the readers.
>>> 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).
Say you store a lot of complex objects via SQL.
To the end-user this is not data, it is only meaningful to
him if it gets suitably rendered.
OTOH labels, names, measurements /are/ data.
What type of application are you used to building?
>>> ...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?
"provide services for retrieving the data" The app may need to provide restriction and rendering, but it should /use/ and transport the retrieved data.
>>>>>>>> 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.
Can you give an example?
To me it looks as if you'd have to come up with
something quite contrived to run against those
restrictions. Am I missing something obvious?
> 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.
Mine is also limited - to mostly highly data intensive systems, some more around messaging.
>>> 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?
No, that would undermine the ad hoc nature. Of course there are security facilities in place so that not every user can see all data.
...
>>>>>>>> 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?
There is no escape in that if you design the data model from a object-persistence point-of-view.
A little copy&paste:
Say you store a lot of complex objects via SQL.
To the end-user this is not data, it is only meaningful
if it gets suitably rendered.
OTOH labels, city-names, measurements /are/ data.
>>>>> ..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?
Off-hand: A program or collection of programs used to support or perform a set of tasks?
http://www.answers.com/topic/application
> The code lying on top of the DBMS?
Not necessarily. Why would every app need a 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 see. Well, that is a tough one. IME it simply /is/. I guess that where a database is used as mere storage, my service has never been called.
> I'm aware that it might be time consuming, so I don't mind if you choose
> not to do it.
Whether off or on-line, the coming days my time is very limited, but after that we can continue if you like. Received on Tue Jun 06 2006 - 00:03:02 CEST