Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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.

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.

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

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

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

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.

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

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

Marshall Received on Mon Jun 05 2006 - 02:10:45 CEST