Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!paul.rutgers.edu!emuleomo From: emuleomo@paul.rutgers.edu (Emuleomo) Newsgroups: comp.databases Subject: Re: RDBMS sux Message-ID: Date: 9 Nov 89 13:11:09 GMT References: <860@anasaz.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 64 In article , hargrove@harlie.sgi.com (Mark Hargrove) writes: > In article <860@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: > [wonders if there are historical reasons for deficiencies in the > relational model and its tools, with example deficiencies cited] > > >Problems: > > (1) No support for vectors or arrays. Now, of course one can define a > > row for each element of an array, but that is not practical in some > > high performance cases. Why was this fundamental data organization > > concept not included. > > I've been designing commercial applications for more than five years using > relational technology, and I've never said to myself, "damn, if only I > had arrays!" The *only* time I've ever needed them at all was for Off course!! I have wished for this *several* times. Its the perfect data structure for *most* of the 1-to-many relationships we come across in real-life development. Suppose you want to be able to display all the invoices for a certain customer in the month of November?? (or whatever the current month is). In order to be able to do a multi-page browse of this list, it would be nice for the DBMS to somehow provide an array-like feature. However, this seems to be present in some 4GLs like Informix 4GL. Also in Ingres I once simulated that feature using "table-field". > > (2) No way (that I know of) to directly locate the "next" row > in a > query. In other words, I read a record off the database. > Now, WITHOUT etc..etc.. > as C). I *know* Unify has this capability, and I'd be astonished if the > other RDBMS players didn't support it as well. Well, what you really need is a NON-SQL based (psuedo relational?) DBMS like Informix 3.3 or Foxbase+ etc.. that allows you to specify access paths based on Index keys. Sometimes I prefer this to SQL especially when *only* one table is involved in a query! > > (3) No standard way to specify the range of a cursor. If I have a > > table - lets say a list of names that is very large, and I want > > to declare a cursor and read <= 20 names, how can I specify that > > other than calling a FETCH 20 times? How can I keep the RDBMS > > from internally reading 40 names, and then handing me them > > one at a time. Note that I am reading by an index, and want them > > in order. > > > You need to give a better example -- I'm not sure what you mean. > What he wants is this... "Let me see the 1st ten people on our mailing list in alphabetical order!" or something in that regard. If the DBMS uses the names of these people as the INDEX, this query becomes *very* trivial. In dBASE/Foxbase etc.. you may write USE MAILING index names LIST NEXT 10 The DBMS should search for and retrieve ONLY THE 1st TEN! Again, what you need is a NON-SQL DBMS! or one that marries both like dBASE IV v1.0 attempted to do. --Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** The ONLY thing we learn from history is that we don't learn from history!