This all sounds to me like full-text search. So I would check if the
full-text search support of sqlite (see http://www.sqlite.org/fts3.html)
is available on android. A quick google search finds pages like
http://bakhtiyor.com/2009/08/sqlite-full-text-search/;. According to
that page, full-text
Has support for this been introduced recently? I have a feeling a while back
I saw something in the change log (maybe 3.0?) but can't seem to find it
again...
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
Hi,
I remember Sqlite supporting 'In-Memory' DB, which is way faster than
normal DB..
Everything that we are doing temporarily, is processed in memory thus
no I/O..
It could be one option to try out.. But am not sure if this is do-able
on android..
http://en.wikipedia.org/wiki/In-memory_database
You have to be careful as the in-Memory database might eat into your RAM
allowance and you could get OutOfMemory errors.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
Ok.
Can you describe more about your set of words. Are they all single
words? how many distinct words are there? what is the distribution of
word lengths? or are they phrases rather than words? Will the size of
this list change?
-broc
On Sep 28, 11:17 pm, mjc147 westmead...@yahoo.co.uk
Just imagine a dictionary where I want to search on the (english)
description. So the word lengths can vary like in any other normal
english text. Number of distinct words is probably a few hundred
thousand. For a deep search I want to search the description using
something like LIKE
On Sep 28, 6:02 am, Broc Seib broc.s...@gmail.com wrote:
Perhaps a Trie data structure?
I can see how that would be useful when searching on prefixes, but
what about when doing free text search?
Also, by mechanism I was thinking more along the lines of database,
flat file (like a CSV) etc
Perhaps a Trie data structure?
On Sep 27, 2009 2:07 PM, mjc147 westmead...@yahoo.co.uk wrote:
That's a nice trick with the indexed column. I thought of something
like that with a column I use for ordering. That column only has a few
distinct values so I could split the query up on each of those
You can't, the thread is down in the SQLite engine doing its work.
I would really look at why your queries are taking so long -- 30 seconds is
just insane. For example, have you created indexes on the appropriate
columns for the query?
On Sat, Sep 26, 2009 at 9:16 AM, mjc147
Most queries take a fraction of a second. However, I want to allow the
user to do deep searches. Think of a dictionary lookup that is
searching the description of an entry. I want to allow the user to
search for something like think and match against something like
thinking. This means using LIKE
The specific search you mention should still benefit from an index,
since it's matching on prefix. If you also wanted it to match
unthinkable, that's a different story. In that case you might want
to consider a storage mechanism other than a relational database.
On Sat, Sep 26, 2009 at 5:58 PM,
Another trick you could try is to use a separate indexed column (the
rowid column for example) to limit your search to some smaller number
of rows, and then perform multiple searches over consecutive parts of
your table. That way each query takes a short amount of time, so you
can stop pretty
That's a nice trick with the indexed column. I thought of something
like that with a column I use for ordering. That column only has a few
distinct values so I could split the query up on each of those values.
The 30 secs is an absolute worst-case scenario. Typical deep searches
take less than
13 matches
Mail list logo
