Reasons for using readable SQLite database

The Android class SQLiteOpenHelper has a method to return a readable database as well as a read and writable database. Currently I am only using writable database and have no issues but I am wondering what the benefit would be to change to using readable only if I am only reading in an async task (or activity).

There might be performance benefits but I have not seen any reference to actual numbers. Also if I keep switching between readable and writable the change has an overhead that might ta开发者_如何学Cke all the performance advantage away.

Does anybody have any real numbers or experience with this? Is it worth implementing separate access?

---

Good question. No numbers from me. The nearest explanation (from SQLLiteOpenHandler javadoc)

"This(getReadableDatabase) will be the same object returned by getWritableDatabase() unless some problem, such as a full disk, requires the database to be opened read-only. In that case, a read-only database object will be returned. If the problem is fixed, a future call to getWritableDatabase() may succeed, in which case the read-only database object will be closed and the read/write object will be returned in the future. "

---

I can't comment on performance benefits but I always try to work on the principle of 'good practice' (or 'best practice' even) for any access to any 'data' sources (text files, DBs or whatever).

Looking at things generically (not Android specific), the decisions to be made when deciding on access level, come down to the operation to be performed as well as any outside influences.

Two examples I can think of...

1. If an external process may have the responsibility of maintaining data - in this case it may have 'opened' the data source in such a way that it blocks all but 'read' access by any other process during the maintenance phase. In this case, your code will be denied access if you request read/write access when it isn't necessary.
2. The risk of compromising data integrity - hacks into systems from the outside world can be achieved via a security hole using internal code which has read/write access to data when it really only needed to have 'read' access.

OK, those points may or may not have relevance to Android (particularly if your data source is specific to your app) but, as I said, I try to look at things generically and use a 'best practice' approach. If I don't need 'write' access, I don't request it.