Subject | RE: [IBDI] Re: Firebird 1 |
---|---|
Author | Paulo Gaspar |
Post date | 2001-06-06T11:27:15Z |
Answer inline:
and on the server sending data that is not going to be used.
Each request tends to be unique because each person searches for something
different... and, often, searches for several different things. Worse,
users stop using a search after browsing 1 or 2 pages and than quit using
it without notice. So, you can end up with an "infinite number" of caches
that will not be reused.
But, of course, the number of rows selected _each time_ is not infinite.
Paulo Gaspar
> -----Original Message-----Nops, it is quite common.
> From: Ed Malloy [mailto:edm@...]
> Sent: Tuesday, June 05, 2001 10:30 PM
>
>
> Hi Fred,
>
> > Suppose one is looking for a list of screenings which fulfill several
> > criteria including screening time between 7pm and midnight, and there
> > are 100 screenings that fullfill the criteria, including 60 that
> > begin between 7pm and 10:30. The initial screen will show 20 of the
> > 100 according to the orderby clauses. Suppose the last item on the
> > first page is an 11 pm screening of the first movie on the list. The
> > second query will exclude all screening of all the rest of the movies
> > that begin before 11 pm.
>
> You are assuming a qry on more than one screening; that's a little
> far-fetched, don't you think?
> > Yes, please read all the posts in this and a related thread. ROWNUMIt is also easy in Java. But then you waste resources both on the client
> > is the index within a result set, not in a table. One of its uses
> > with Oracle is for selecting subsets of the result set.
>
> If Oracle can do it on the, presumably, server side, it should be
> equally easy on the client's side, or, assuming that you can integerate
> interbase with php, on the client side.
and on the server sending data that is not going to be used.
> > No problem at all for some tasks. If you read the messages from PauloHe is talking about caching the data.
> > to which Ann was responding you will see that for some types of
> > application you will need an infinite number of arrays with different
> > sorting orders as indexes to the structure you are proposing, in
> > other words, the programmer will have to write a mini relational
> > database.
>
> I fail to see how you would ever need an infinate number of anything for
> a task which oracle performs on the server side.
Each request tends to be unique because each person searches for something
different... and, often, searches for several different things. Worse,
users stop using a search after browsing 1 or 2 pages and than quit using
it without notice. So, you can end up with an "infinite number" of caches
that will not be reused.
But, of course, the number of rows selected _each time_ is not infinite.
> ...Have fun,
Paulo Gaspar