MySQL。应该使用什么方法，规范化或减少表的数量

Question

假设我必须为一个组织(比如银行)做一个网络应用程序。这里的成员可以有不同的帐户，如贷款帐户、GDCS 帐户、存款帐户等。为了存储数据，我想到了两种方法。我正在采取以存款账户为例。(成员(member)可以在任意一天存入金额。)

1.]将每个成员(member)的存款详细信息存储在一个以成员(member) ID 作为字段的表中。2.]将单个成员(member)的存款详细信息存储在名为member_id_deposits的单个表中

在情况1中，将有多个具有相同member_id的记录。因此存在数据冗余，因为member_id是冗余的。在情况2中，没有冗余，因为不同日期的整个存款详细信息都存储在每个成员(member)的单个表中。但是在这种情况下，如果有100000个成员(member)，则将有100000个表。

那么应该采用哪种方法，是表数量较少的方法，还是减少冗余但表数量非常多的方法？

我知道数据库设计的主要关注点是减少冗余。所以从这个角度来看，第二种设计更好。但是它有很多表。有大量表有什么问题吗？是数据库中可以存储的最大表数有限制。表多的数据库查询是否会很慢。

Answer 1

为什么有人认为旨在支持数十或数百 GB 数据的数据库在无数个小表上而不是在一个大表上表现更好？

我可以很容易地想到在不同的表(最终是数据库)之间拆分客户数据的情况只有一个实例。那就是当它是当前问题的明确要求时。例如，律师事务所可能必须将客户数据存储在不同的地方，因为这在法律上是必要的。银行的投资部门可能必须将数据存储在与银行其他部门不同的位置，以防止访问。

拥有大量 table 有什么缺点？以下是我能想到的一些:

1. 为特定客户找到合适的餐 table 并不是免费的。访问数据库中一百个表中的一个基本上不需要任何开销。数据库可能需要一些时间才能访问十万个中的一个。
2. 您的数据库可能不允许那么多表。
3. 如果表格很小，页面可能会稀疏地填充。大大增加了存储数据的开销。
4. “跨表”所需的任何信息(例如，“每个客户的平均客户余额是多少？”)都变得非常难以回答，以至于没有人会同时提出此类问题。
5. 所有查询都必须是动态的，这意味着您无法在编写查询时对查询进行错误检查。
6. 在大多数数据库中，更改表名称的动态查询需要重新编译，因此每个查询都会产生编译开销。
7. 维护是一场噩梦，因为您必须更改无数的表。另一方面，这会阻碍额外的开发，而这可能会使应用程序更加稳定;)。

我确信其他人还会想到其他原因。简而言之，数据库是为大型表设计的。规范化并不是要消除冗余(数据的冗余副本，是的)。按照设计的方式使用数据库。