多个客户端表或大型整体表

Question

我最近接手了一个链接到多年前最初设计的大型MySQL数据库的项目，需要一些帮助。

目前，每个客户端有5个表，用于存储用户信息，交易历史记录，日志等。但是，我们目前有大约900个客户申请使用我们的服务，平均每周申请5个新客户。因此，DB已经发展到近5000个表并且不断增加。我们的许多客户最终都没有使用我们的服务，所以他们的表都是空的，但仍然在数据库中。

最初的数据库设计师说它是以这种方式创建的，因此如果某个表遭到破坏，它就不会泄露任何其他客户端的信息。

当我用PHP重新设计项目时，我正在考虑重新设计数据库以使用客户端唯一ID引用整体用户，事务历史记录，日志等表。

这种方法是正确的还是数据库保持不变？

您能否看到任何可能的安全/性能问题

感谢您的帮助

Answer 1

您应该将系统重新设计为只有五个表，并使用一个单独的列来标识该行所属的客户端。 SQL可以很好地处理大型表，因此您不必担心性能问题。事实上，在许多情况下，拥有许多表可能会影响性能。

这有很多优点。您将能够一次优化所有客户端的表结构。不再尝试向300个表添加索引以满足某些性能目标。管理数据库，管理表，备份 - 所有这些都应该更容易使用单个表。

您可能会发现数据库的大小甚至更小。这是因为，平均而言，这些数千个表中的每一个都在最后填充了半页。这将从成千上万的半页变为一页。

一个缺点是安全性。表上的安全性比表中的一行更容易。如果这是一个问题，您可能需要考虑这些要求。

Answer 2

这可能仅仅是一种品味问题，但我会发现将这些信息存储在尽可能少的表格中更为自然 - 因而也是可维护的。大多数（如果不是所有）数据库ORM都会期望这样的结构，并且没有理由重新发明那个轮子。

从安全性的角度来看，听起来这个项目可以被描述为一个Web应用程序。显然，我不知道您正在处理的业务逻辑的现实，但似乎无论表权限如何，所有对数据库的访问都将通过代码库进行，在这种情况下，应用程序本身需要所有表的完全权限 - 使表保持分离的任何优点都无效。

如果安全措施存在令人信服的理由 - 比如，将数据独立于Web应用程序提供给数据库的不同服务，我仍然会探索在应用程序层而不是数据库层处理该身份验证的方法。以这种方式处理安全规则会容易得多。如果用户ID等于user_id列，则单个安全规则只允许用户查看一行数据，而不是在5000多个不同的地方设置规则。更简单，更容易理解，因此更易于维护（并且可能更多安全）。

不同的人以不同的方式处理数据库。我是一名Web开发人员，因此我将数据库视为存储数据的地方，仅此而已，因为它始终是专用且通常是单用途的数据库安装，并且我在应用程序级别处理所有其他逻辑。有些人将数据库视为应用程序本身，他们为大规模，分布式，多用户系统更广泛地使用内置安全功能 - 但老实说，我对这些方案的评论不够充分确切地说应该绘制该线的位置。