is sqlite overhead expensive?

[cybohemia]

I'm thinking of populating a UITableView where each cell is a row from a database table.

The way I learned to interact with the sqlite3 database is, for each call, I'd go through a series of steps including opening the database, doing the select, closing the database and releasing the things that need to be released.

Since each screen will show several rows (when things get populated) I was wondering if, instead of re-opening the database for each row (in the cellForRowAtIndexPath method), I were to get all the data in one go and save it in a dictionary.

The tradeoff is that, if things are edited and I'm using an intermediary dictionary rather than directly with the database, then I have to do the bookkeeping, sync it up with the database, etc.

I read the posting on the efficiency but I'm not referring to the size of the data or access speed, just the overhead of setting up and cleaning up for even the simplest call and whether those are considered expensive enough computationally so that batching them up and saving them in a low-overhead data structure would make sense.

Or, maybe I shouldn't do the opening/closing in cellForRowAtIndexPath but somewhere else (like viewDidLoad and viewDidDisappear)?

Any thoughts?

[rendezvouscp]

I don’t know what the overhead is, but I can presume it’s less efficient than the method I use in my app. Here are my suggestions:
-Retrieve all of the data from the database when the view loads. Don’t do it individually; make a select for all of the information you need.
-Store the information in an array or a dictionary. When the table is being loaded, have the cells refer to the array instead of making queries to the database.
-Create a new type of object for your data. Instead of handling the edit/delete from the table view, send messages to the object and handle the database “stuff” there.

Hopefully that’ll get you started on the right foot.
-Chasen

[cybohemia]

Thanks, Chasen - I was definitely thinking the technique I learned seemed a bit inefficient!