It's a pretty simple case really - I have a list of songs and I currently just create a table like so;
create table songs (_id INTEGER PRIMARY KEY, name TEXT, author TEXT, product TEXT, type TEXT) ; create index nameidx on songs (name) ; and populate it with around 400,000 entries. There are only a few (maybe around a 100) types, but the other field are pretty varied (but no field is unique). >From the application the user can search for a particular song by name or author normally, so I've tried for instance; select * from songs where name like 'winter%' ; // Takes around 2 seconds select * from songs where name like 'stardust%' ; // Takes around 8-10 seconds select * from songs where name like 'winter%' and author like 'Ben %' ; // Takes around 8-10 seconds select * from (select * from songs where name like 'winter%') where author like 'Ben%' ; // Takes around 8-10 seconds Before the index all my searches where 8-10 seconds... (Times as I remembered them from earlier today, not 100% sure) -- Sasq On Jun 30, 9:40 pm, Hamy <[email protected]> wrote: > Generally speaking, performing LIKE on any database is slow, so if you > can avoid it that would be better. If you can post your structure and > query, perhaps we can figure out a way to get the same results without > a LIKE. > > Thanks, > Hamy > > PS - skink, would you reference your previous post? I would like to > read it! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
