Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.databases Subject: Re: SQL Poser Message-ID: Date: 6 Jun 90 18:21:35 GMT References: <6588@umd5.umd.edu> <1990Jun1.132731.6699@oracle.com> <1990Jun4.151555.3479@oracle.com> <2371@anasaz.UUCP> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 96 In-reply-to: john@anasaz.UUCP's message of 5 Jun 90 13:55:52 GMT In article <2371@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: > > Hopefully the RDBMS vendor community will realize that SQL is far from an > ideal query language for many commercial systems, and will thus put in the > extensions needed to both the language AND the model. If not, I predict > that OODB's or network DB's w/OODB's will cause the current RDBMS success > to stall! SQL is definitely lacking when it comes to many things that users are beginning to want. Everyone from Dr. Codd on down has admitted that at one point or another. The drive for standards (IMHO) has caused more harm than good in these areas because the standard is based on today's capabilities (which by now is a couple of years old) rather than where the definition should eventually be. If past track record holds, 2-3 years from now we'll probably have a relational language standard that incorporates OO concepts (whether it will be called SQL is anyone's guess). The relational model, on the other hand, is consistent with what it was defined to be consistent with (sets). In fact, it is more consistent (aka standard) than either the networked model or the OO model. What is needed (if anything) is a clear and complete OO model. Such a model will either supplant the relational model (because the relational model will simply be a subset of the OO model) or be incorporated into the prevailing model of the time (because the prevailing model will have the base functionality needed to represent the new model). > SQL + RDBMS suffers from many shortcomings, including: > (1) Lack of support for truly ordered data. I still have trouble understanding "truly ordered data". What is it that it is not expressed in an "ORDER BY" clause? The relational model works with sets and sets are not ordered. Ordering is a post-condition placed on the set of objects that meet a query. However, although a set does not imply an order, an index does. Is this "having your cake and eating it too"? > (2) Lack of the concept of a subset defined by position in an ordered > sequence plus count. The problem I have with this is the time-dependent nature of the subset. People usuall desire this capability so that they can close a cursor, go off and do other things, and come back to the cursor to pick up where they left off. The one question I have is what if the subset changed in between accesses (a likely thing in a high transaction environment)? That is, suppose what was the fifth item is now the sixth item because a new second item was added. > (3) The previous poster's comment about inability to express a > hierarchical query. This is definitely an area that needs more treatment in relational implementations. The relational model seems fully capable of representing such concepts, the problem is how to efficiently access such an arrangement and return it in a representation that can be dealt with. What does a hierarchical set look like? > From the standpoint of one who is concerned with performance, I view SQL > and RDBMS as designed with NO throught to performance, with indexes sort of > tossed in as an afterthought (while collective purists held their noses). Do you think an OODBMS gives any more thought to performance? Everything I've seen about OODBs leads me to believe the opposite -- the only performance considerations are the ones the database (not database system) designer designs in. The system designers merely provide functionality to help the database designer improve performance. IMHO, I think relational systems have a leg up in this area because of a more concrete model. > Now, I know that various vendors have various "extensions" to the language, > or subroutines that represent extensions, that help with performance. > However, as a creator of large scale software products (hotel central > reservation systems, among others), we also need STANDARDIZATION and MARKET > ACCEPTANCE. Define STANDARDIZATION? How does it differ from MARKET ACCEPTANCE? Is what the market accepts the "defacto" standard or are you looking for more in the name of standardization (a complete model, something that will last more than a couple of years, etc.)? After all, a standard is a standard is a standard... > On top of this, what I really want is an Object Oriented database. I > eagerly await OODBs reaching enough market penetration that we can use them > portably. And... I hope the standards that evolve or are created by > committee take into account real world problems such as described above. Don't jump too quickly on the OODB bandwagon. There may be nothing wrong with OODB, but move too quickly and you may be back in the same boat a couple of years from now. Its obvious from your message above that all your "questions" about relational databases have not been answered. Have all your "questions" been answered by object oriented databases (both those above and those yet to be stated)? (BTW, that's a rhetorical question directed at the group) -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"