Android 一个大数据库与多个小数据库

我的应用程序处理几个类似的数据集。也就是说，它们存储在相同的表中，但数据不同。用户可以创建更多的数据集。在任何情况下，这些数据集都保证是不相交的。一个数据集中永远不会有任何数据以某种方式链接到另一个数据集中的数据

我想知道，对于每个数据集，是否最好有一个专用的数据库，而不是将所有数据都放在一个大数据库中

如果用户在较小的数据库上工作，我希望查找时间会缩短。在我担心查找时间之前，是否有经验法则，一个数据库（或表）可以容纳多少个条目

我能想到的一个缺点是打开数据库会产生一些开销。但是，我不希望用户频繁切换数据集

考虑这个例子：

数据库包含公司、客户、产品和订单的表格。公司从不共享客户或产品，因此公司是不相交的数据集。然而，所有的产品、客户和订单都放在一张大桌子上（分别放在一张桌子上）

对数据库的查询可能包括：

• 特定客户的所有订单
• 特定客户订购的所有产品
• 订购特定产品的所有客户
• 等等

这些查询有一个共同点，即它们总是在单个公司的上下文中发出。然而，由于数据库不知道这个逻辑分区，所以将搜索所有客户机、产品和订单

如果我有几个数据库，每个公司都有一个，我的逻辑分区会被反映出来，只会搜索相关的数据。不过，我不确定拥有这么多数据库的开销

因为我是数据库模式设计的新手，所以我想把这个想法抛出去看看，几个数据库是否真的是一个好主意

更新：

---

如果不清楚的话：数据库将在Android手机上，而不是在云端或其他地方。

你的问题让我想起了一些讨论关系数据库和将数据存储为json或其他noSQL选项之间区别的文章。如果不做一些关于你想要完成什么以及你可能达到什么程度的研究，就很难做出判断。但是，从维护的角度来看，您的数据库模式及其更改的灵活性将有利于单个db实例。您也可以使用多个表。

这是纯性能的问题。你应该知道你的数据库应该有多大，你应该把所有的数据存储在不同的数据库中，如果这个量大约是一般数据库的20%，而且只会减少，那么使用一个数据库，如果它可以增加分配50%个或更多的通用数据库，你可以考虑单独的数据库。p> 数据库的一般大小也很重要。现代设备可以相对舒适地与高达500mb的数据库（约500000条重线路）一起工作。它将处理更多的内容，但需要对UX、UI和scheme进行一些修改，以最小化调用（分页、索引等）。虽然如果你运行这样一个应用程序的一些薄弱的设备，它会崩溃

还知道SQLite如何工作（RAM中的虚拟表），它高度依赖于应用程序可访问的RAM量。最好使用大小为100mb的db

正如你们所看到的，并没有单一的方法——你们必须根据你们的应用程序用例和预测的数据库大小来选择

---

希望这个答案对你有所帮助。

没有经验法则。恐怕查找时间并不完全取决于条目的数量。这取决于几个因素，例如但不限于-

这张桌子多胖啊

表索引

数据的存储方式，例如布尔真/假或字符串是/否，在有300万条记录的表中

硬件尺寸

主键/外键关系（某种程度上连接到上面的第1点）

作为一般方法，一种数据库理论是可取的。现在的服务器功能非常强大，在处理性能优化时有多种选择，例如-

云数据库提供了选择大小的灵活性

大数据

内存数据库

分析服务，如SSAS

水平可扩展的NoSQL数据库，例如FireStore

现在，使用一个数据库的最大好处是-您的开发和测试将很快。这是什么意思？假设您需要在一个表中添加/删除/修改一个字段。现在，如果您有10个不同的数据库，那么您将需要在10个不同的位置进行完全相同的更改，然后对其进行测试。如果更改频繁，那么最终可能会编写一个通用脚本。而且这个脚本总是有可能中断，例如数据库更改、补丁更新等等。然而，在一个数据库的情况下，这些努力是直接的十分之一。另一个好处是，数据库管理/监控将很容易，例如添加索引

几个月前，我有一个类似的需求，我有一个类似的应用程序（移动+网络）。设置是相似的。不同的公司访问数据。并且允许特定公司的用户查看与其公司相关的数据。我所做的就是在几乎每个表中添加一列指定为ORGCODE。超过12位客户正在愉快地共享这些表，没有任何问题

---

免责声明：在不了解您的用例和性能需求的情况下，以上所有内容都是非常通用的

我会选择一个数据库-更少的维护和可能出错的东西。

---

确保其优化和索引

数据库将在手机上。我不认为更改数据库模式会有什么大不了的，因为它们是相同的，所以共享相同的房间实体。我只是打开它们