Thanks for the advice Helen.

I live in Santiago de Chile (that's way south from most of you!)
which has over 5 mill. inhabitants. The whole city is bounded aprox.
between [-33.353, -70.790] and [-33.623, -70.492] coordinates.

Having 1 mill. records spread in the above "bi-dimensional address
space", can be considered "enough granularity"? The probability for
two rows to be on the exact same latitud or longitud is small,
perhaps 1 in 500000 (purely subjective number).

Unfortunatly the most frequent constraint (WHERE clause) used for
geographic display is the map bounding box. When rendering general
purpose information layers (such as streets, or addresses) the only
precondition is the desired viewable area.

--- In ib-support@y..., Helen Borrie <helebor@t...> wrote:
> At 09:32 PM 03-10-02 +0000, you wrote:
> >Hmmm...
> ><ME THINKING TWICE>
> >Ok, I could use a generator and simply read it's current value.
> ></THINKING>
>
> SELECT MAX() and reading the latest value from a generator won't be
> guaranteed to be the same in a multi-user environment...the latest
value
> from a generator may be used for an insert within a transaction
that hasn't
> committed yet - and might be rolled back. Generators themselves
are
> outside transaction control...
>
> >Sometimes the best answer is another question. Thanks Sean!
>
> Sometimes the best answer is an answer, too. :-)
>
>
> >Do you have any clue about my other question? The fact is that we
use
> >a product called "Autodesk Mapguide" that generates vectorial maps.
> >Some information layers may be retrived from database. The map
server
> >queries the database with something like:
> >
> >SELECT <some col>
> > FROM <some table>
> > WHERE <lat col> BETWEEN <lat min> AND <lat max>
> > AND <lon col> BETWEEN <lon min> AND <lon max>
> >
> >We use Oracle as our RDBMS, but I would like to use FB as a
> >development platform (Oracle may be expensive to license and
> >administer, but it *is* the best performing DBMS I've ever used). I
> >was wondering how the index compresion could negativly affect the
> >above query. Any pointers would be welcome.
>
> If you have two-way indexes on each of <lat col> and <lon col>, the
engine
> will seek BETWEEN ranges intelligently. One thing that will
detrimentally
> affect the speed of indexed searches is if any of these indexes has
most of
> its index values concentrated in a small number of actual values.
What
> types are these data, i.e. is there enough granularity in each
individual
> value to ensure a reasonably low frequency of duplication?
Latitude and
> longitude matter in binary trees, too. :)
>
> An important factor in the speed of searching is how effectively
you can
> limit the "catchment" of searches through your WHERE criteria. In
the
> example above, perhaps by limiting another indexed column (where...
AND
> LOCALE starting with 'A' AND ADATE > CURRENT_DATE - 10) or
whatever.
>
> heLen