用于Android应用程序的SQLite数据库，具有潜在的多个用户

我有一个带有SQLite数据库的应用程序，用于存储用户帐户的信息。我设计数据库时假设应用程序只有一个用户。因此，用户ID不存储在数据库中（但存储在服务器上的中央数据库中）。但是，可以注销应用程序并让另一个用户登录，但目前的问题是，他们的数据被下载，然后附加到另一个用户的数据中。这不是我想要的，但我不确定如何最好地改变数据库设计来解决这个问题。我曾想过：

每个用户一个数据库。如果用户只在朋友的手机上登录一次，而不再登录，则可能导致不必要的数据存储。而且我想这可能很难管理

将用户ID列添加到所有表中，这样追加不会导致问题。仍然存在（1）所具有的不必要的数据问题，并且失去了1的模块性

当用户注销时清除数据库。如果用户在服务器上有大量数据，那么在应用程序启动时同步数据将需要很长时间（这将在另一个线程上完成，但仍然很痛苦）

---

这些方法之一好吗？或者有更好的方法吗？

我会选择选项1。将其作为一个单独的文件保存将确保拥有多个数据库不会对性能产生任何影响

您可以将用户ID附加到数据库文件名。您可以使用某种LRU系统，在该系统中，如果您的数据库超过4个（或者如果您的数据量超过一定数量），则会自动删除最旧的数据库

---

这个选择的具体细节将取决于您，因为您知道您希望使用多少数据存储，以及有多少用户可能在同一台设备上使用该应用。

这实际上取决于您的要求，但是第三个选项似乎不太实用。如果你想这么做，那么这与卸载和重新安装你的应用程序是一样的

我可能更倾向于使用选项2，但这取决于您希望在数据库中执行的操作。e、 g.如果您希望跨所有用户而不是单个用户进行统计或查询，并且用户之间共享公共数据

---

如果您担心存储大小，请编写一个服务，清除属于在特定时间段内未登录的任何用户的数据。

我喜欢LRU方法-我正在考虑跟踪它们的修改时间，但您的两个建议都更易于实现。我真的怀疑不止一个用户会在同一台设备上使用该应用程序，但你永远不知道！谢谢：）提案1比提案2的实际优势是什么。。？什么“模块化”丢失了？什么是“绩效影响”？有人听说过规范化和关系数据库原则吗？如何为设备上保存的多个数据库执行升级/更改数据库结构？