OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Opinions requested

[ Lists Home | Date Index | Thread Index ]
  • From: Jerome McDonough <jmcdonou@library.berkeley.edu>
  • To: xml-dev@ic.ac.uk
  • 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 
about that.

>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:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS