data management (was: The wisdom of the object mentors)
Date: Sun, 04 Jun 2006 23:34:24 +0200
Message-ID: <44835194$0$31644$e4fe514c_at_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.
>> ...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.
> ...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.
> 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.
>>> ..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.
>>>>>> 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.
>>>> 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 - 23:34:24 CEST