Heh heh. I wasn't asking you to actually USE convert to sqlite memory in your
library. I was just saying that for a few xqueries yours a really useful
library, but for lots of queries against a large array, the performance of
first converting to an sqlite memory database and then querying that
Well, it's only a case of "I expect ..." so we shouldn't trust my
intuition until we've benchmarked it a bit :-)
Having said that - we will still be using script to iterate over the
keys/elements of the array, so there is likely to be some cost there -
even before we allow sqlite to index
I was thinking about that. Depends on what you mean by par. If you are not
indexing array values, then you will have to touch every array element each
time you query. It's back to one pass sql conversion then, and you would get
all the benefits of sql in the bargain. The only time an array
Alex Tweedly wrote:
> I expect the searches etc. would be faster with SQL / memory database
Both use hashed lookups to find data. What would be needed to bring LC
array queries on par with SQLite?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop,
No, no SQL database involved.
The array is kept untouched - although you can use the xaCopy function
to make a copy of some subset of the data, in general it's going to be
more efficient (both space and time) to keep the array.
There is no relational anything - it's just intended for wen you
Thanks Alex. Couple questions:
Does this convert to an SQL database? If so, are there commands for ordering?
The advantage to converting to a memory based sqLite database is that there are
features unique to SQL, like relational queries and sorting by multiple columns
that you cannot get by
Bob Sneidar and Richard Gaskin said :
> Essentially it's for finding things in an array. You might say I could
> do the same thing by iterating through all the elements of an array,
> but what if I wanted to do multiple queries? It's easier for me to
> write SQL queries than it is to code
