数据库体系结构，列中的大多数空字段

Question

我在MySQL中有一个数据库表，根据一项新功能，我们可以通过两种方式实现-1.在同一个表本身中创建一个新列（可为空），这种方法的缺点是-该列将具有95- 98％的时间为NULL条目。 2.使用现有表的外键创建一个新表。

所以这两种架构看起来像这样-

1. table1 - <id, ..., new_column>

2. table1 - <id, ...>, table2 - <id, table1_id, ...>

第一种方法遵循非规范化方法，而第二种方法遵循规范化方法。 但是由于这是一个现实问题，所以有时可以采用非规范化方法。

我对数据库设计的某些假设可能是错误的，您认为解决此类问题的更好方法是什么？

Answer 1

如果您可以提供特定的示例，这将非常有帮助-“我应该添加一个可能为空的列”不容易回答。

非常笼统，规范，直到你能证明你做别的事情。 设计数据库的易读性和防错性； 添加额外的表所花的精力要比弄清楚为什么为什么当您更改一些意外忘记了非规范化的代码时，您的应用程序突然在12个月内报告不正确的数据。

那么，此可空列是否是实体的属性？ 不是所有的people有一个middle name属性-完全合理的有一个空列。 还是因为方便而只是将其附加到实体上，但实际上不是属性吗？

例如，一个person可能有一个employer ，而该雇主可能有一个address ； 理想情况下，您将创建一个带有address属性的employer表； 连接employer_address到人可能会觉得自己像一个快捷键（我不关心除地址以外的任何-我永远不需要知道有多少人为该雇主工作）。

这可能看起来像是您正在省力省力-但它的可读性较差（因此将来的开发人员会想知道您为什么这样做），易发生错误（您可能会为单个雇主获得不正确或不一致的地址），并且更难更改未来（祝您好运，仅根据地址确定有多少人为给定的雇主工作）。

Answer 2

在这些情况下，“垂直分区”可能是有利的

• 通常，第二个表中的列会丢失，因此该表中的行较少。 注意：您可以使用LEFT JOIN获得NULL 。
• 第二个表中的列很大，但很少使用。 进行SELECT *时有性能上的劣势，有些列是TEXT / BLOB 。 垂直分区可以帮助您提高速度。 （在InnoDB中选择适当的ROW_FORMAT实际上消除了这一优势。）
• 最常见的查询不需要第二个表的列。
• 你得 无需停机添加列。 根据MySQL / MariaDB版本，主表上的ALTER .. ADD COLUMN ..可能会长时间阻止其使用。

我怀疑这种方式只能拆分100个表格中的1个。 这会使读者感到困惑，等等。我上面列出的好处很少，并且这些好处可能不足以证明这样做是合理的。

第二个表将具有与主表相同的PRIMARY KEY ，但没有AUTO_INCREMENT 。 这两个表将没有相同的辅助键。 并请注意，您不能在两个表中都有包含列的复合索引。

如果新列是一堆“属性”，例如在“商店”应用程序中，请考虑将它们放入JSON列中。 这是开放式的，但是很难与WHERE或ORDER BY一起使用。