database - 多个模式与庞大的表

Closed. This question needs details or clarity。它当前不接受答案。

想改善这个问题吗？添加详细信息，并通过editing this post阐明问题。

上个月关闭。

Improve this question

考虑一个移动设备管理器系统，该系统包含每个用户的信息，例如一个表，该表存储了他已在电话上安装的应用程序，审核详细信息，通知信息等。明智的做法是使用相应的表为每个用户创建单独的架构？一个用户的表数量很大，每个表大约有30个表。将所有这些信息放入这些表(进而创建巨大的表？)中有一个单独的架构，还是为每个用户创建一个架构，会更好？

提前致谢

最佳答案

I want to see which method is more efficient in terms of querying in the database.

在 Multi-Tenancy 数据库中，查询只是问题的一部分。问题的其他部分是成本，数据隔离和保护，维护以及灾难恢复。这些意义重大；您不能只考虑 Multi-Tenancy 数据库中的查询效率。
Multi-Tenancy 解决方案的范围从每个租户一个数据库(不共享)到每个租户一行(共享所有内容)。
“不共享任何内容”，“单独的数据库”或每个租户一个数据库

每个客户端最昂贵。 (大量的客户端意味着大量的服务器。)

最高程度的数据隔离。

单个租户的灾难恢复非常简单明了。

从理论上讲，维护比较困难，因为需要在每个数据库中进行更改。但是您的dbms可能很容易支持在每个数据库中运行存储过程。 (例如，SQL Server具有未记录的系统存储过程，例如sp_msforeachdb。您可能可以编写自己的存储过程。)

“最不共享”也是最容易自定义的，但是这也带来了更多的维护问题。例如，每个租户可能使用不同的使用模式，这表明每个租户可能需要一些其他租户不需要的索引。与“无共享”无关紧要； “共享一切”是不可能的(如下)。

每个表的最低行数。查询速度接近最佳。

“共享所有内容”或“共享架构”或“每个星球一个数据库”

每个租户最便宜。

最低数据隔离度。每个表都有一列，用于标识行属于哪个租户。由于每个表中都混合有租户行，因此意外地暴露其他租户的数据相对简单。

单个租户的灾难恢复相对复杂；您必须还原许多表中的单个行。另一方面，单租户灾难相对罕见。大多数灾难可能会影响所有租户。

鉴于所有租户共享表，结构维护更简单。但是，这会增加通信负担，因为您必须与每个租户沟通并协调每个更改。它不容易定制。

每个表的最高行数。快速查询比较困难，但它取决于租户数和行数。您可以轻松进入VLDB领域。