SQLite or Core Data for a linear but big database?

I have a databas开发者_C百科e with many entries but only one field. Think of a basic list with about 200k names ordered alphabetically. The user of the app will be able to search this list and get autocompletions on his requests.

Would SQLite or CoreData perform better for this approach? Or won't either be needed at since it's just one field of data?

Thanks in advance.

Edit: more info: All the entries are static and won't be edited at all

I think that using FMDB backed by SQLLite might be a better solution for this. In Core Data, each row would be represented by one object instance, which in turn would hold a string... that's a lot of wrapping and indirection of results.

However the best idea would be to test this - since it's such a simple model, putting together an SQLLite database and CoreData database, then populating each with 200k items and timing searches against them would be the best bet. It could be that CoreData's more advanced caching may help for something like a progressive search string where the user inputs then deletes characters.

Don't forget to mark the row as indexed! That will help in either case.

SQLite and CoreData would pretty much perform the same, since one of the backend stores can be (and by default is) SQLite, so basically it is the same if you use one or the other. Main advantage of Core Data is all the added benefits from the framework, like caching of results, object oriented way to interact with the database and so on...

More important, perhaps, than the choice of datastore is the choice of autocompletion algorithm and the decisions relating to how to structure the data in the datastore.

You don't want the algorithm's "kicking in" to cause the user's keystrokes, or some of them at least, to get swallowed up. Have you ever typed a search string into Google only to find that the first few characters you typed are not there in the text box?

You might want to delay the string-match until at least three characters have been typed and/or you might want to store your data in a denormalized manner which could be more amenable to autocompletion.

For example, your PK or key might be "alt" and this delimited string might be the value for that key:

          altar,alter,alteration,altercation,alternate,alternation,alternator,although,
          altimeter,altitude,alto,altogether,altruism,altruist

rather than having each of those words occupy its own row.