Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!anasaz!john
From: john@anasaz.UUCP (John Moore)
Newsgroups: comp.databases
Subject: Re: RDBMS sux
Message-ID: <888@anasaz.UUCP>
Date: 10 Nov 89 13:52:47 GMT
References: <860@anasaz.UUCP> <CIMSHOP!DAVIDM.89Nov7102914@uunet.UU.NET> <881@anasaz.UUCP> <16647@dartvax.Dartmouth.EDU>
Reply-To: john@anasaz.UUCP (John Moore)
Organization: Anasazi Inc, Phoenix AZ
Lines: 86

In article <16647@dartvax.Dartmouth.EDU> carl.pedersen@dartmouth.edu (Carl Pedersen) writes:
>In the case of arrays, "you don't understand it".  It would not
>make sense to have an "array" concept in a relational system.

It makes sense in two ways:
  (1) In the access language (and my gripe here is really with SQL), the
      array syntax may be convenient. This is not a problem with
      the relational model per se, but with SQL.
  (2) When considering access efficiency, which is really where my 
      concern came from. If I have data that I am likely to
      access as an array, but the RDBMS scatters it all over
      the disk (after all, relational sets have no inherent
      ordering), I can't access it efficiently. This is a real world
      problem that we have today. Now, some vendors attempt to
      do something about this, but this is outside the relational model
      or SQL. Informix allows "clustering" of data to get around this
      problem. It suffers from two difficulties: (1) efficiency is
      not all that high because all key fields of the row are stored
      every time, so the number of elements per disk block is MUCH lower
      than it would be with a true array type; (2) it does not
      maintain the ordering over inserts and deletes, so it is not
      useful for a dynamic database.  Oracle does it better - it
      allows a clustering where a number of rows with the same key
      can be stored in the same sector, without duplicating the key data.
      I don't remember what Unify, Sybase or Ingress do.
]
]>I have a hotel inventory that can be described as a two
]dimensional array (at each property) of room types by date
]
]Yes, or it can be described as a table, which you have already
]discovered.  This is just a syntax issue, not a relational vs
]array issue.  That table is operationally equivalent to an array,
]that is, there is nothing you can do with an array that you can't
]do with that table.  There is no reason to make a distinction.

THE TABLE IS NOT OPERATIONALLY EQUIVALENT TO AN
ARRAY! It is semantically equivalent, but when you factor in performance,
or ease of use of syntax, it is not the same! I suspect that it is
this confusion of semantics with operational equivalence (common
in academia) that has lead to the lack of features in RDBMS/SQL.

]You may think that the syntax of operations using the RDBMS is
]clumsier than some other syntax that you imagine to be associated
]with arrays, but that is an orthogonal issue.  There's no reason
]why one could not define a syntax for accessing a table that is
]just as concise as what is used to access an array.  I don't
]speak RTI's QUEL, language, but I suspect it's a bit closer to
]what you re asking for than, say, SQL.  By the way, some silly

The problem is that we are trying to base our product on a
multivendor standard, and that forces use to use SQL. There are lots
of better solutions around to our problems, but they are not
standard. It is the standard (explicit, or implicit by what
is available) that concerns me.

]In the case where you need to get the next 20 records, or the
]next record, etc., with or without using cursors, I think you
]have identified a real problem with at least some products.
]
]As I'm sure you have heard, relational systems work with sets,
]and sets don't have an inherent order.  Of course, you can
]define ordering in purely set-theoretic terms, but it's too
]clumsy.  That's why languages like SQL have ways to specify the
]order of a result.  To be honest with you, I think the only
]reason some RDBMS vendors don't provide what you need is because
]they have't gotten around to it, yet.  I think eventually they
]will.  There are applications that need this functionality.

I think they haven't done it because cursors provide the appropriate 
functionality, as long as you don't look under the hood and see what
it is doing to your performance, and as long as you are willing
to live with restrictions on which process can do a FETCH NEXT. (ie
the process per user model).
]
]By the way, if anybody has any neat ideas about how to handle
]problems like this in current SQL implementations, especially
]ORACLE, I'd love to hear them.

You and me both! (except, in my case, Informix)


-- 
John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
7525 Clearwater Pkwy, Scottsdale, AZ 85253
The 2nd amendment is about military weapons, NOT JUST hunting weapons!