Re: Array vs Temporary Tables, benchmark testing

["Wanko, Christopher G, CFCTR" <apollo@ATT.COM>]

> While theoretically the books tell us that arrays *should* be
> quicker since they are memory resident, when you throw in the overhead of
a
> bubble sort or comparing each record in the array a bazillion times, I
have
> found that creating a temp table with indexes and then using the
> database to perform sorting based on selection criteria to be faster in
most
> cases.  Of course this would be dependent on the hardware configuration
you are using...

"Everyone has plan, until they get hit." -Mike Tyson

This whole "temp table vs. array" debate is silly.  There aren't enough
parameters in the
problem to gauge if one has the distinct advantage over the other.

Listen.  There are times, plenty of times, where a school notebook and a
sharp pencil will
utterly defeat the best spreadsheet program or database.  Only the most
complicated of
household budgets can really exploit Quicken, dig?  So why see everything in
terms of
the most popular or obvious solution?

If you think arrays, for certain sized data, makes perfect sense, then take
the time to
build a good library of array routines.  If you do it once, and do it
correctly, it'll
always be faster than database access for a certain size.

Tables are the end-result of a database engine, specifically built for
storing, searching,
and sorting relational data (duh).  If the minimum cost of using tables is
met, you use
your database engine.  Only you can decide minimum cost: connectivity (do I
need to run
this program with a tenuous or nonexistent connection to a server), speed,
reliability,
portability, et. al. .

In conclusion, if you have the need to manipulate or work with small batches
of flatfile
or simple data and find that an array library (if it existed) would be a
WONDERFUL addition
to your shop, then absorb the pain and build it.  At least you have the
ability to construct
tools to build tools, even if you eventually move to tables.

-Chris