Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Mon, 05 Jun 2006 20:28:31 +0200
Message-ID: <e61t40$sgf$1_at_sunce.iskon.hr>
Marshall wrote:
> Sasa wrote:
>
>>mAsterdam wrote: >> >>>>>Do you agree that >>>>> x A DBMS is not storage. >>>> >>>>No >>> >>>Heh. I should have re-asked this question earlier. >>> >>>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. >> >>This is of course stretching it to far, obviously the database offers >>much more than for example fprintf/fscanf do. >> >>However, I remain by the claim that DBMS is primarily a storage. As far >>as I know, everything in there revolves around persisted data. >>Whenever you issue an insert statement, the data persists (not taking >>temp tables and rollbacks into account). Whenever you select, you >>retrieve the persisted data.
>
>
> Usually the term "persistent data" refers to data that persists beyond
> the lifetime of the process that created it. It doesn't just mean that
> the data fails to vanish the moment after creation. We do not,
> for example, consider a local variable to be "persistent storage"
> even though you can assign to it, and later in the body of the
> function, use it in an expression.
Agreed
> I agree that persistence is an important service for an enterprise
> dbms. But it is not part of the definition of dbms, since we
> can have things that manage data but that do not persist them.
> For example, there exist a variety of "embedded dbms" products
> that lack any persistence mechanism, instead simply providing
> an SQL interface to the application it is embedded in.
This is interesting, as I didn't think about the "non persistable" database until now, and it does shift the perpective somewhat. What are the typical practical usages of such.
> Would you agree that it would not be correct to describe as
> "primary" a feature of something that was neither necessary
> nor sufficient for that thing to meet the definition? We
Yes.
> would not, for example, say that a human was *primarily*
> something with two legs, even though the vast majority
> of humans do, in fact, have two legs. Because some
> humans do not have two legs, and some things with
> two legs are not human. (Birds, gorillas, etc.)
> We might say that human has two legs most of the time,
> though; I would support saying that a dbms has
> persistence most of the time.
With your previous argument in mind (which is to me the first concrete) I could agree that dbms is not merely a storage all of the time.
However, it doesn't shift the perspective that radically. If you would support saying that a dbms has persistence most of the time, your argument doesn't make me change my view most of the time.
I seem a bit phylosophical here, but bear in mind that I did come with a biased view (which I already emphasized). I am interested in seeing why do you not see database as a persistence, and in some aspect you have convinced me. Are there more arguments?
>
>
>>>>> x Sharing data is not a consequence of persistence. >>>> >>>>No >>> >>> >>>Please try to clearly explain how it /is/, then. >> >>Since the data is persisted it is readily available to any app if it has >>access to the persisted data.
>
>
> But it is the access, not the persistence, that makes the sharing.
Which makes the RDBMS exactly why different as opposed to the flat file?
>
>
>
>>>>>>>How do you provide the users with ad hoc query facilities? >>>>>> >>>>>>Where I had to do this, the 'ad hoc' query feature amounted to >>>>>>combinations of simple filters (which would map to the WHERE part of >>>>>>the query). When multiple filters were used in most cases only >>>>>>logical and was supported. The set of attributes available in >>>>>>filtering was predefined. There was no relational filtering (e.g. >>>>>>give me all orders for customers which satisfy...) >>>>>>That was more than enough for the end users. >>>>> >>>>>Short answer: you don't. Why so many words? >>>>>I should have put 'How' in my question between parentheses. >>>> >>>>Depends on what you really mean by ad hoc queries. >>> >>>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 :-)
>
>
> That's not correct though. Queries are against a database, not
> a dbms; the dbms is the execution agent of the queries.
And its query related features are all that you have. Whatever has been defined during the design of the query language of the specific DBMS is what you have at your disposal.
> When you design an enterprise schema, you don't begin to
> have all the queries that will be necessary over the lifetime
> of the database.
>
>
>
>>How often have you seen this requirement?
>
>
> *Every* database I have worked with has had this requirement.
I was thinking more along the line what was needed for the end users.
>
>
>>Was the requirement that >>absolutely every possible query supported by underlying storage is >>allowed (and not some meaningful subset)?
>
>
> Yes. It has to be, because you don't know what ad hoc queries
> will be coming along. (By the definition of "ad hoc query.")
> This of course includes every different join you can imagine.
>
>
>
>>How was it implemented?
>
>
> You get this feature for free by using SQL.
>
>
>
>>By simply allowing a user to enter the SQL queries in plain text?
>
>
> It is common that there is a class of users that wants this.
>
>
>
>>If yes, what sort of users were those?
>
>
> Analysts. Sometimes engineers. Sometimes even the more
> sophisticated ops users want it. In a few, frightening cases,
> PMs.
So you then allow them to query the database, maybe provide the UI from the application, or simply tell them to use the query editor of the database?
>
>
>>I would sure like to have my entire user base consisting of people who >>are good in writing SQL statements.
>
>
> It's never the *entire* user base; otherwise you wouldn't need *any*
> application code. :-) By the numbers, it's usually a fairly small
> count of users, compared to the regular end-users.
>
>
>
>>Yes, but 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.
>
>
> Again, there are different kinds of users. End-users often have
> very limited querying needs. Analysts often have extremely
> sophisticated querying needs.
Fair enough.
So if I'm seeing this right you're saying that some users need to have the full query abilities. This is usually small subset of users but it's still there. Given that appropriate DBMS is chosen with flexible query language, such users can leverage the query language of the DBMS. Once such decision is made it means that some users use the DBMS directly. The DBMS hence qualifies as more than a storage, it actually exposes an interface (in the form of its query language) to some end users.
Is that the general idea of the argumentation?
>
> Marshall
>
Sasa Received on Mon Jun 05 2006 - 20:28:31 CEST