Question

I have an app with an SQLite database for storing information for a user’s account. I designed the database on the assumption that the app would only have one user. As such, the user’s ID isn’t stored in the database (but it is stored in a central database on a server). However, it is possible to logout of the app and let another user log in, but the problem with this is at the moment, their data is downloaded and then appended to the other user’s data. This is not what I want to happen, but I’m not sure how best to change the databse design to solve this. I have thought about:

1. One database per user. Could result in unecessary data storage if a user just logs in once on their friend’s phone and never again. Also I guess this could be hard to manage.
2. Add a user ID column to all tables, so appending doesn’t cause a problem. Still has the unecessary data issue that (1) has, and loses 1’s modularity.
3. Wipe the database when the user logs out. If the user has a lot of data on the server, it will take a long time to sync the data when the application starts (this will be done on another thread, but it’s still a pain).

Is one of these approaches good? Or is there a better way to do this?

Answer 1

I would go for option 1. Keeping it as a separate file will ensure that there won’t be any performance implication whatsoever by having multiple databases.

You can append the user ID to the database filename. You could have some sort of LRU system where you automatically delete the oldest database if you have more than 4 (or if you exceed a certain amount of data).

The specifics of this choice would be up to you, since you know how much data storage you’d like to use up, and how many users would be likely to use the app on the same device.