0

假设我必须为一个组织做一个网络应用程序，比如银行。在这里，一个成员可以有不同的账户，比如贷款账户、GDCS 账户、存款账户等。为了存储数据，我想到了两种方法。我将存款账户用于示例。（会员可以在任何一天存入金额。）

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

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

那么应该遵循哪种方法，一种具有较少表的方法，或者一种减少冗余但具有大量表的方法？

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

4

1 回答 1

2

为什么有人会认为设计用于支持数十或数百 GB 数据的数据库在数以万计的小表上比在一张大表上表现更好？

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

有很多桌子有什么缺点？以下是我能想到的一些：

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

我敢肯定还有其他人会想到的其他原因。简而言之，数据库是为大型表设计的。规范化不是要消除冗余（数据的冗余副本，是的）。以他们设计使用的方式使用数据库。

于 2013-07-24T19:56:49.873 回答