创建大数据的数据库表

Question

我正在制作一个客户管理应用程序，其中存储了employee ， admin和company的数据。 将来该数据库将注册数百家公司。 我正在考虑采用最佳的数据库设计方法。

我可以想到2种方法：

1. 为每个公司分别制作应用程序的所有表格
2. 将所有数据存储在应用数据库中

您能建议最好的方法吗？

请注意，所有3个表都是基于ID链接的，将有数百个公司，每个公司将有许多管理员，每个管理员将有数百名员工。 与安全性和查询性能相关的最佳方法是什么

Answer 1

查询的性能并不太取决于表的大小，而是更多地取决于该表上的索引。 因此，您需要根据需要放置聚簇索引和非聚簇索引，并且我可以保证最多10 GB的数据不会出现任何问题

Answer 2

有了您提供的部分信息，您似乎需要3个规范化表 ，以及诸如查找和其他内容之类的辅助数据。

但是，在设计数据库时，您需要考虑更多的要点，例如安全性，可见性，客户端访问方法等。

例如，如果您要确保隔离，并且不允许用户对他人的数据具有任何可见性，则可以为每个公司动态创建一个架构，为每个架构动态创建用户和访问权限。 然后，您需要在DAL中支持这些东西，实际上这将是非常繁琐的。

DAl的另一种方法是公开总是返回一个公司子集的视图。

我建议采用标准化方法的一个重要原因是这种方式的维护会容易得多。

从SQL的角度来看，我看不到具有很多表或只有3个表的任何性能优势，索引的效率和智能DAL会有所作为。

Answer 3

这是我大多数网络业务服务所共有的一个经典问题：对于所涉及的因素的讨论，谷歌“多租户架构”。

几乎可以肯定，您希望将所有公司放在一组公用的表中：每个数据表都应引用公司关键字，所有查询都应结合该关键字以及其他条件。 这样可以实现最佳的整体性能，并避免了数百次重复视图，存储过程等的潜在维护麻烦，或者如果您希望添加字段或表，则必须对数百个表应用相同的结构更改，从而避免了潜在的维护噩梦。

为了确保您不会无意间混杂来自不同客户的数据，通过一组经过验证的存储过程（所有过程都将公司ID作为参数）进行所有数据访问可能会很有用。

数以百计的并行数据库无法很好地扩展：DB服务器将不断地将表和索引推出内存以容纳下一个查询，从而导致磁盘崩溃和性能下降。 那条路只有痛苦。

Answer 4

根据您的应用程序的用例，没有“最佳”方法。 请说明您的应用程序将提供的操作，以便我们进一步了解您的问题。

要存储的数据似乎是结构化的，因此乍一看关系数据库就可以很好地工作，但是要坚持我上面标记的观点。

Answer 5

您根本没有说过该数据如何链接，或者它们之间是否存在任何链接。 但是，您大概需要3个表。

1. 员工表
2. 管理员表
3. 公司表

每个目录都具有必需的属性，如果没有其他信息，我将无法提供更多指导。