Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!asuvax!anasaz!john From: john@anasaz.UUCP (John Moore) Newsgroups: comp.databases Subject: Re: SQL Poser Message-ID: <2371@anasaz.UUCP> Date: 5 Jun 90 13:55:52 GMT References: <6588@umd5.umd.edu> <1990Jun1.132731.6699@oracle.com> <1990Jun4.151555.3479@oracle.com> Reply-To: john@anasaz.UUCP (John Moore) Organization: Anasazi, Inc. Lines: 107 In article <1990Jun4.151555.3479@oracle.com> tgreenla@oracle.UUCP (Terry Greenlaw) writes: ]In article jkrueger@dgis.dtic.dla.mil (Jon) writes: ]>Sounds great. Except for one small problem: the only reason I use ]>SQL is compatibility and applications portability. ] ]Then you must be one very frustrated individual, since SQL compatability between ]vendors falls into the "virgin nymphomaniac" class of events. I don't think SQL mmmmm... its not quite that bad! We've run the same stuff on Oracle and Informix, for example. ]is mature enough at this point to freeze expansion of the language in the name ]of compatability. The extensions that Oracle and other vendors have provided ]are the driving forces that will lead to a language robust enough to be used ]in a unextended form. For now, the basic SQL syntax is a good starting point ]for understanding a relational query language, but I wouldn't be relying on it ]for portability across vendors. ] ]> Clearly at this ]>point you can't have this and a cleanly designed query language ]>too, but with SQL extensions you can have neither. ]> ]>Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger ] ]I think you will find that you can, but it's name will be SQL II. 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 + RDBMS suffers from many shortcomings, including: (1) Lack of support for truly ordered data (2) Lack of the concept of a subset defined by position in an ordered sequence plus count. (3) The previous poster's comment about inability to express a hierarchical query. 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). (and Jon Krueger, please don't give me this BS about not having the RIGHT tools - we MUST use large-market share tools or our customers will not buy from us!), While it is true that much performance issues should be the concern of the database engine and hidden from most users, that doesn't mean that the user should have no significant control over it. We like to use an approach where we oversee performance issues in low level primitives that WE provide, which do performance oriented SQL (as much as possible), and turning database tables into "objects classes", the use of which is transparent to the main application. Unfortunately, with SQL, we had to write our own DDL and DML extensions of SQL, using preprocessors, in order to achieve both this encapsulation of function and to allow central control of performance and complex integrity rules. 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. Let me give a simple example of a performance issue where the language fails to help. There are plenty of others. Lets say we have a table of names and related data. I want to read 5 names starting at a certain point so that I can display in a screen that allows a max of 5. Finally, I'm doing this with a front-end/back-end implementation such as Oracle 6 or Informix Turbo/OnLine using embedded queries. I have to define a cursor such as SELECT stuff FROM my-table WHERE name LIKE :host_variable ; or ... WHERE name > :host_variable ; Then, I open the cursor and do 5 fetches. Now, what goes on behind my back? Unless the database is prescient, or there is a NON-STANDARD extension to SQL, it has no way of knowing that I want exactly 5. So, a typical back-end/front-end system will fetch one message buffer's worth of data, and send it back. If this is more than 5, I have payed to read a bunch of records I will never use. If it is less than 5, I end up with extra message exchanges between the front end and the back-end. If sometime later, after the cursor has been closed [sometimes you are forced to close a cursor for practical reasons], I want name #6. I have no way of saying to SQL "hey you, give me the next row after row #x according to such and such ordering rule." I end up having to cook up some wierd query that may or may not give me exactly what I want (depending on whether a primary key enters into the where clause). 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. others. -- John Moore HAM:NJ7E/CAP:T-Bird 381 {asuvax,mcdphx}!anasaz!john john@anasaz.UUCP Voice: (602) 951-9326 (day or eve) FAX:602-861-7642 Advice: Long palladium, USnail: 7525 Clearwater Pkwy, Scottsdale, AZ 85253 ......: Short petroleum Opinion: Support ALL of the bill of rights, INCLUDING the 2nd amendment!