| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: data management
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.
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.
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.
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 :-)
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?
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)?
But not the subset of the data?
>> 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.
>> ... 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.
>>>> 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.
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.
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.
:-)
> 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 - 12:59:48 CDT
 |
 |