emuleomo@paul.rutgers.edu (Emuleomo) (11/09/89)
In article <HARGROVE.89Nov6202259@harlie.sgi.com>, 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!
carl@eleazar.dartmouth.edu (Carl Pedersen) (11/10/89)
In one of his articles, john@anasaz.UUCP (John Moore) wrote: >My first posting was a query about historical reasons for >the lack of certain features in RDBMS'. All responses so far have >been of the form: > why fight it > you don't understand it >Does anyone have any idea why the above mentioned deficiencies exist, >or how to get around them In the case of arrays, "you don't understand it". It would not make sense to have an "array" concept in a relational system. >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. 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 language might require you to access what it calls an array by saying something like "FOO_ARRAY WHERE DIMENSION_INDEX(1) = '01/22/89' AND DIMENSION_INDEX(2) = 'BRIDAL SUITE'", instead of just "FOO_ARRAY('01/22/89','BRIDAL SUITE')". 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. We have an email system, for example, that wants to show the user the first 20 messages in their in-box. When they scroll down, it wants to get the next 20, and so on. Then, when they scroll up, it wants to be able to get the *previous* 20 messages, and so on. We don't really want to number the messages because 1) users are allowed to display their in-box in several different orders and 2) new messages can appear at any time. Cursors are only a partial solution to this problem. I think it would make sense to provide a way to say something like, "Give me N rows from this ordered set starting at the Ith row." Perhaps there are better ways to specify this, but you get the idea. I don't think this would be any more out of place in a language like SQL than "order by" is. 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.
hargrove@harlie.sgi.com (Mark Hargrove) (11/10/89)
In article <Nov.9.08.11.08.1989.12756@paul.rutgers.edu> emuleomo@paul.rutgers.edu (Emuleomo) writes: >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. Yeah, I think I agree here. SQL is just a tool, and it sounds like you're trying to use embedded SQL (or a lousy 4GL) for something it doesn't do well. What you're trying to do is *perfectly reasonable*, and if SQL doesn't do it well, use another tool. Unify's ACCELL 4GL environment, for example, has an attribute that can be set called FIND_LIMIT, which controls the cardinality of a FIND (Query) operation. IF you set it at, say, 20, it will get the first 20 records of the found set, then fetch the next 20 when the user (via the application) wants the next set, etc. This same functionality could also be implemented in Unify's C-HLI. How about some ideas from you lurkers at Ingres, Oracle and Sybase? How would *you* solve this absolutely reasonable problem with your product? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.corp.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039
jkrueger@dgis.dtic.dla.mil (Jon) (11/10/89)
john@anasaz.UUCP (John Moore) writes: >RDBMS are being sold as THE solution to modern >commercial processing Sane people do not sell this notion, and sane people do not buy it. Don't deplore the hype, explore it. Phrases like "the solution" and "modern" and "commercial processing" are part of the hype, not part of its analysis. In any calm analysis they have little status as meaningful terms anyway. Try "useful", or "productive". >and yet I am asked to accept that it is built on >set processing, with no reference to "next", "previous", etc! In the real >world, these are very important concerns. Next and previous with respect to what, the sort? That defines an ordinal scale in which any and every item's next and previous could change with respect to any and every other item with any change to the database. What is defined by this metric? Current adjacency? If you'll examine a few examples I think you'll find you're either overloading the notion of primary key or else mixing the usefulness of commonly executed queries with integrities defined on the database at all times. >room on their screen for 20 names. How can I only get 20 names? See my private mail to you for an example. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
dlw@odi.com (Dan Weinreb) (11/10/89)
In article <881@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
My first posting was a query about historical reasons for
the lack of certain features in RDBMS'. All responses so far have
been of the form:
why fight it
you don't understand it
Not at all; several of the responses, like mine, were of the form "You
asked about the relational model, but the deficiencies you note
actually don't have anything to do with the relational model per se,
but rather the way current RDBMS products work." I realize that this
doesn't help solve your problems; I and others were just trying to
clarify the question. Anyway, you rightly don't care about the
relational model, or what a theoretical DBMS might do; you're asking
about actual existing products.
Also, I think the "why fight it" answers were not intended to give
offense, or to tell you that nobody cares. They merely meant "I don't
understand why cursors don't solve your problem, would you please
explain more specifically". In your subsequent postings, you have
indeed explained more specifically, and now the people who are
experienced with commercial RDBMS products should be able to provide
more useful answers. Good luck.john@anasaz.UUCP (John Moore) (11/10/89)
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!
john@anasaz.UUCP (John Moore) (11/10/89)
Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger writes
in private email that I can't seem to get a response path to:
]
]>Yes... I have a hotel inventory that can be described as a two
]>dimensional array (at each property) of room types by date. I
]>can represent this is an RDBMS with rows where each row has
]>a room type and date attribute, followed by the data I wish to keep
]>for this cell. However, it is more graceful, since the data is
]>logically an array, and it is certainly more efficient with CURRENT
]>RDBMS products, to represent the data syntactically as an array.
]
]The data is logically a set. You may implement it as an array,
]but it is less efficient: try inserting a new room. You may
The efficiency depends on the relative frequency of inserting vs.
searching.
]also implement it as a table, or hierarchy, or network; all
]data models have advantages and disadvantages. I take it one
]correct set of schema is:
]
] +-------+
] | rooms | hotel room type
] +-------+----------+-------+--------+
] | West End | D-104 | single |
] | East End | 37 | double |
] | NiteLite | 11 | suite |
] | NoTell | A/100 | bridal |
] +----------+-------+--------+
No, more correct would be:
rooms hotel room-type date available
West End double 12/1/89 30
West End double 12/2/89 20
West End double 12/3/89 00
West End double 12/4/89 12
West End double 12/5/89 30
West End double 12/6/89 30
...
West End single 12/1/89 30
...
Note: total # dates might be 730, # room-types per hotel could be 20,
total # hotesl could be thousands
Query: find me a room in Chicago for Jan 3 - Jan 14, 1989.
assume another table gives list of hotels in chicago.
Now, we can readily frame the query in SQL using a normal table
organization. However, when we examine what the RDBMS will do to
solve the query, given that the set has no ordering, it will have to
read a number of rows from all over the disk. On the other hand,
if we were to group a bunch of room types and dates together into
single rows, we can read many fewer rows from the disk. Not only that,
the total amount of data read can be less, since the key information
need not be read for each "cell", only for each "array".
Note that
even with current tools, we could do this, but we would have to
name each "cell" in a logical array with a different column name,
which is certainly not very graceful! In other words, we could
have a table that looks like:
hotel date avd1r1 avd2r1 avd3r1 avd4r1 avd1r2 avd2r2 avd3r2 ....
One ends up either generating
dynamic queries (not normally very efficient, but an approach that
we considered) or writing code that knows the name of every column.
This is not very convenient.
The other approach using current tools is to use clustering. Oracle
does it best of the ones I have seen (see related posting). Unfortunately
this is not standard, and thus code which depends on this is not
portable between RDBMS vendors.
I could readily come up with other examples where arrays are even
more natural.
]>I have a list of 100,000 names. I wish to display
]>the first 20 names following J. Smith. If I get a "more" response
]>from the operator, I wish to display the next 20 names. Furthermore,
]>I wish to process these requests with separate Unix processes, so
]>the standard cursor approach (just leaving a cursor open) doesn't
]>do the job.
]
]Wrong. Counterexample:
]
] +---------+
] | broaden | term bt
] +---------+----------------------+-----------------------+
] | CPU | COMPUTER |
] | CPU | PROCESSOR |
] | MEMORY | COMPUTER |
] +----------------------+-----------------------+
]
]#include <stdio.h>
]#define NOT_FOUND 100 /* correct for RTI INGRES only */
^^^this definition also works for Informix, by the way
]exec sql include sqlca;
]#define BUNCH 20
]
]fetchit(ref)
]exec sql begin declare section;
]char *ref;
]exec sql end declare section;
]{
] exec sql begin declare section;
] char c_term[50];
] char c_bt[50];
] exec sql end declare section;
] int counter = 0;
]
] printf("fetching broader terms for \"%s\"\n", ref);
] exec sql declare csr cursor for
] select trim(term), trim(bt) from broaden where term = :ref;
] exec sql open csr;
]
] while (!sqlca.sqlcode) {
] exec sql fetch csr into :c_term, :c_bt;
] if (sqlca.sqlcode == NOT_FOUND) {
] break;
] else {
] printf("for %s, try %s\n", c_term, c_bt);
] if (++counter%BUNCH == BUNCH)
] prompt("more");
] }
] }
] exec sql close csr;
]}
]
]#define TMPSIZE 100
]prompt(what)
]char *what;
]{
] char tmp[TMPSIZE];
] printf("%s: ", what);
] fgets(tmp, TMPSIZE - 1, stdin);
]}
]
]Let's not debate what can't be done when I'm currently doing it.
No, you are not doing it! Look at my conditions again! Your example
only works with a single process. Try sending the "more" prompt, and
then taking the answer into another Unix process!
]
]>Why doesn't the
]>basic model deal with these issues?
]
]It's no part of set operations.
]
]>This is a case where
]>the "set" is defined by ordering - the FIRST n rows meeting
]>a certain criteria, as opposed to ALL rows meeting the criteria.
]
]OK, you want to get a car wash and a burger What's the union of the
]first 20 car washes nearest you with the first 20 burger joints near
]you? Do you think it's your best route? If you answered yes, you're
]wrong. The 21st of each might define a much better route. Set
]operations are defined only under certain limits.
]
]There's nothing wrong with the convenience of sorting, or presenting
]a bunch of rows at a time, or not requiring all queries to run to
]completion before making the first match available for display. But
]these are not defined by the model; they are ways for vendors to add
]value to the model. Some vendors do.
]
And this is the whole problem! What it means is that the model is
inadequate to solve many real world problems. It would be much
better to upgrade the standard to solve these problems than to
leave it to individual vendors. In this modern day of
portable programs, I see no reason why an application should
only work with one vendor's RDBMS, just because the standard
is inadequate! Please, we need real solutions, not ivory tower
theorems!
]
]You can shop for a vendor who provides this feature. Note that if he
]provides it without enabling you to turn it off, you simply trade
]throughput for latency: no net win.
]
Again, if we can get it into the standard, the whole user community
wins!
]>]> Note that I am reading by an index, and want them in order.
]
]The two issues are orthogonal, and are mutually orthogonal to the
]ability to display rows as soon as they qualify, which three issues are
]wholly orthogonal to performance, since again you're simply trading
]latency for throughput.
But, latency and throughput are DIFFERENT measures of performance. It
is not unusual for a contract to specify LATENCY (x% transactions
complete in y seconds) AND throughput (...at a rate of z transactions
per second). Both need to be controllable.
]
]>]All commercial products have ways to break out of a select loop.
]
]>You miss the point. The FETCH is the way you do a select loop. However,
]>commercial products (especially client-server types) tend to pre-fetch a
]>group of rows when a cursor is declared, and then feed them to you one
]>at a time. I am interested in performance so want to have the internal
]>RDBMS engine only fetch as many rows as I am interested in.
]
]Pre-fetching is transparent to the model and embedded use both. If you
]want to flush results as soon as each qualifies, you can. This has
]nothing to do with cursors; it's true for retrieve loops as well, which
]use no cursors at all.
Jon, please try to understand. I am dealing with high performance, REAL
WORLD transaction processing. I really don't care what the model says,
or how elegant or complete it says, if it can't solve the problems
portably, efficiently and predictably!
P.S. If you respond, please do it on the net, since I have to
reply there anyhow.
...
PPS - assault rifles have nothing to do with RDBMS. It's just too
much of a pain to change my signature for each group. Sorry.
--
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!kitchel@iuvax.cs.indiana.edu (Sid Kitchel) (11/11/89)
john@anasaz.UUCP (John Moore) has asked why the relational model does not contain array access. Several posters have tried to set him straight on the nature of relations in the model and how that makes the notion of array unnecessary. On the implementation front, it is clear that array operations as opposed to one-at-time cursors could be useful to the application writer. In fact ORACLE agrees so much with this view that they have provided array- oriented insert and retrieval in their embedded SQL facility. I have used it while helping to implement DOME (Distributed Object Management Environment), an object-oriented database system built on top of ORACLE. DOME Software Corp.'s experience is that the array operations significantly speed up their object server. One of the reason's that ORACLE was chosen as their first platform was the array facility. Now if the other vendors would also follow up on this and speed up basic operations.... --Sid -- Sid Kitchel ===================================== Computer Science Department kitchel@iuvax.cs.indiana.edu Indiana University skitchel@gold.bacs.indiana.edu Bloomington, Indiana 47405-4101...............skitchel@iubacs.BITNET
jkrueger@dgis.dtic.dla.mil (Jon) (11/11/89)
hargrove@harlie.sgi.com (Mark Hargrove) writes: >How would *you* solve this absolutely reasonable problem with your product? Any product that supports embedded query language has already solved it. After receiving each row, programs may count it, display it, pause, prompt the user. Mechanisms such as the one you cite are not necessary nor, in my view, desirable. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
jkrueger@dgis.dtic.dla.mil (Jon) (11/11/89)
kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes: >ORACLE [has] provided array-oriented insert and retrieval >in their embedded SQL facility. The operation insert is not defined on the data type array. If you believe it is, please tell us the difference between an array and a set. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?
peno@kps.UUCP (Pekka Nousiainen /DP) (11/12/89)
In article <29421@iuvax.cs.indiana.edu> kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes: > On the implementation front, it is clear that array operations as >opposed to one-at-time cursors could be useful to the application writer. >In fact ORACLE agrees so much with this view that they have provided array- >oriented insert and retrieval in their embedded SQL facility. Using arrays speeds up "batch" operations significantly (factor of 5) but in my experience arrays are of no help to the application programmer. The situation is similar to reads and writes in C language. Reading and writing one character at a time is most convenient, but very expensive if one uses the read() and write() system calls. Hence C has a buffered interface to read and write - <stdio>. The problem with Oracle arrays is that there is no analogue of <stdio>. Each instance must handle the buffering details. While they are not much, they do amount to something if one has tens or hundreds of programs to maintain. -- peno@kps.se
dgh@unify.UUCP (David Harrington) (11/14/89)
In article <888@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: > >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. > Accell/SQL, the 4GL and applications generator form Unify, is the standard you want. It will let you do all the NEXT RECORD processing you have been talking about in this discussion, and it will run your application on all the databases that have been discussed here. Accell/SQL's 4GL isn't SQL, but if you need SQL Unify and every other database have that, too. With it you get performance AND SQL functionality, not to mention database independance. David Harrington Director, Accell Development Unify Corp.
dgh@unify.UUCP (David Harrington) (11/15/89)
In article <1244@unify.UUCP> dgh@unify.UUCP (David Harrington) writes: > >Accell/SQL's 4GL isn't SQL, but if you need SQL Unify and every other database >have that, too. With it you get performance AND SQL functionality, not to >mention database independance. Re-reading this last paragraph, it occurs to me that one could get the wrong idea about Accell/SQL. So: Let me re-phrase that. Accell/SQL's 4GL has full embedded SQL functionality, if not strict ANSI syntax, and much, much more. > > >David Harrington >Director, Accell Development >Unify Corp.
catone@dsl.cis.upenn.edu (Tony Catone) (11/29/89)
In article <881@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >You tell me! Here is the application: I have a reservation system with >500,000 names in it. Someone wants to display a list of similar >names (where similar can be resolved to >= "xxx"). They only have >room on their screen for 20 names. How can I only get 20 names? I believe Oracle's SQL-Forms module allows you to specify this automatically. Give them a call and ask for the SQL-Forms demo disk; it will show you what you need to know. Be forewarned, however, that Oracle sales people can be a bit much to deal with sometimes, so you really want to ask for the product literature and demo disk and then decide for yourself. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
nico@unify.uucp (Nico Nierenberg) (11/29/89)
In article <17393@netnews.upenn.edu> catone@dsl.cis.upenn.edu (Tony Catone) writes: >In article <881@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >>You tell me! Here is the application: I have a reservation system with >>500,000 names in it. Someone wants to display a list of similar >>names (where similar can be resolved to >= "xxx"). They only have >>room on their screen for 20 names. How can I only get 20 names? > >I believe Oracle's SQL-Forms module allows you to specify this automatically. >Give them a call and ask for the SQL-Forms demo disk; it will show you what >you need to know. Be forewarned, however, that Oracle sales people can be >a bit much to deal with sometimes, so you really want to ask for the product >literature and demo disk and then decide for yourself. Accell from Unify can do this using the browse feature, and if you set up your indexes correclty it will only look at the rows which are actually displayed. The user can then decide to browse through additional rows. Best of all it will do it on any one of several data bases. Nicolas Nierenberg Unify Corp.