Lists Home |
Date Index |
- From: Jerome McDonough <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 08 Mar 1999 09:02:38 -0800
Thanks for the update on SIM. It's definitely more advanced in its
development than I thought. A few additional comments, and a clarification:
At 03:40 PM 3/6/1999 +1100, Marcelo Cantos wrote:
>More important than any specifics, however, is the issue of what you
>call a DBMS. To me, a DBMS is a database management system (seems
>painfully obvious, but I think it bears repeating). You may argue
>that a product is not a DBMS if it does not support feature X, and I
>don't entirely disagree. When one talks of a DBMS one is conjuring up
>a certain image in the mind of the listener, and that image may well
>include feature X. To be fair to SIM, however, the essence of a DBMS
>is that it manages a collection of data. If it doesn't support
>transactions, this does not entail that it does not manage data.
>Rather it simply has limits on the way the data is managed (i.e. it
>doesn't manage data as well as one would like).
>You clearly believe that transaction support is part of the essence of
>what makes a DBMS. I disagree, indeed, I profoundly disagree. There
>is nothing in the concept of a database that mandates any such
>requirement. Rather I would say that transaction support is an
>important issue for any _good_ DBMS. Likewise for referential
>integrity and concurrency (and, for that matter, support for
>declarative queries, use of indexes, a rich set of fundamental data
>types, etc.). If I recall correctly, dBase III was generally
>acknowledged to be a DBMS though it lacked most of these requirements,
>and could barely even call itself relational!
I agree with all of the above, and I didn't mean to particularly single
out transaction support. In addition to the point you raise that a DBMS
calls to mind a particular set of features (not all of which need to
be present to qualify a system as a DBMS), I'd add that particular systems
are developed based on previous work within a particular paradigm (oh man,
referencing Kuhn before I've even had coffee -- been a grad student too long)
and I see SIM as much more following in the lineage of IR systems than
DBMS systems. I'll grant there's overlap, and SIM is obviously moving
towards a graceful integration of the two areas, but I'd characterize
it as moving from an IR engine towards a combined IR/DBMS system.
>I guess this all boils down to what's in a name. At the end of the
>day, it is far more important to know what a product does and does not
>do than what you call it.
Agreed, but as you mentioned, particular names invoke an understanding
of what a system does/what features it may be expected to support, etc.
While these understandings may overlap from one person to the next, often
they don't, and I think DBMS are an example of an area where they can mean
quite different things to different people. Hence, the frequency of people
saying 'DBMS don't handle SGML/XML' occuring side by side with people
saying 'what, are you crazy? Of course they do.'
>I am sceptical that any RDBMS vendor can come to the party in terms of
>performance. Past attempts to try to force text into a relational,
>table or object based paradigm have not reaped great success (Oracle's
>ConText comes to mind as an example of how forcing a square peg into a
>round hole requires sacrificing the edges of performance). I would be
>surprised if any of the major database vendors would be prepared to
>venture away from their core competency (the relational model) to
>address the performance issues.
I share your skepticism, but we can hope. If nothing else, there appears
to be at least the dawnings of an understanding among the major DBMS
vendors that there's a huge market for text management/retrieval products.
Some of the approaches taken by the object-oriented database folks, like
Informix's data blades, struck me as having promise.
>I strongly disagree that SIM doesn't handle SGML/XML well.
Ah, now here, I'm afraid you're reading words into my mouth. To clarify,
I think SIM handles SGML/XML very well indeed; one of the best I've seen,
in fact. I said I don't think any DBMS handles SGML/XML well, but I also
excluded SIM from the DBMS category. Sorry, I should have been clearer
>From what you've said, though, SIM does appear to be shaping up as
a very interesting IR/DBMS hybrid. The referential integrity hooks
are a very nice plus. I have one piece of advice: promote yourselves
more! :) I looked over the SIM web site before my post, and didn't see
any discussion of the new features you're working on. A few words about
future directions you're exploring for your product would be a good thing.
Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......)
Library Systems Office, 386 Doe, U.C. Berkeley | \ * * /
Berkeley, CA 94720-6000 (510) 642-5168 | \ <> /
"Well, it looks easy enough...." | \ -- / SGNORMPF!!!
-- From the Famous Last Words file | ||||
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)