在这种情况下，非规范化可以接受吗？

Question

我有以下 locations 表：

----------------------------------------------------------
| ID | zoneID | storeID | address | latitude | longitude |
----------------------------------------------------------

和 phones 表：

-----------------------
| locationID | number |
-----------------------

现在，请记住，对于任何捐赠商店，最多可以包含五个电话号码。顺序并不重要。

最近，我们需要添加另一个表，其中包含商店相关信息，其中还包括电话号码。

现在，这个新表不应用 locationID，因此我们无法将电话存储在以前的电话表中。

保持数据库规范化最终需要 2 个新表和总共 4 个联接来检索数据。对其进行非规范化会呈现旧表，如下所示：

----------------------------------------------------------------------------------
| ID | zoneID | storeID | address | latitude | longitude | phone1 | ... | phone5 |
----------------------------------------------------------------------------------

总共有 2 个表和 2 个连接。

我不喜欢使用 data1、data2、data3 字段，因为这可能会带来巨大的痛苦。那么，你有什么看法呢。

Answer 1

我认为，就其价值而言，反规范化是当且仅当您确实存在性能问题时才可以采取的措施来获得性能。我总是针对 3NF 进行设计，并且仅在绝对必要时才恢复。

您所做的并不是为了让您的查询看起来更好。任何体面的数据库开发人员都不会担心中等复杂的 SQL 语句，尽管我必须承认我见过一些让我不寒而栗的数百行语句 - 请注意，这些语句来自无法控制模式的客户： DBA 首先会重新设计架构以避免出现这样的问题。

但是，只要您对非规范化所施加的限制感到满意，您就可以做任何您想做的事情。这并不是说有一群 3NF 警察在地球上漫游寻找违规者:-​​)

我能看到的直接限制（可能还有其他限制）是：

• 你将被限制（最初，没有架构更改）最多 5 部手机每个位置的数量。从您的描述来看，您似乎不认为这是一个问题。
• 您将浪费空间来存储不必要的数据。换句话说，每行都使用五个数字的空间，无论它们实际有什么，尽管这种影响可能很小（例如，如果它们是 varchar 且可为空）。
• 查找电话号码的查询将会很复杂，因为您必须检查五个不同的列。我不知道这是否是您的用例之一，所以它可能无关紧要。

不过，您可能应该选择一种方式（我不确定这是否是您的意图）。如果我遇到一个在存储表和单独的电话号码表中都有电话号码的架构，我会特别恼火，尤其如果它们彼此不一致。即使当我去规范化时，我也倾向于使用插入/更新触发器来确保保持数据一致性。

Answer 2

我认为你的问题源于错误的模型。

为什么有位置 ID 和商店 ID？一家商店可以占据多个地点吗？
电话号码是否与地理位置相关？

只需通过 StoreId 输入所有内容，您的问题就会消失。

Answer 3

只需尝试将新表与旧位置表关联起来，因为这两个表都代表商店，您应该能够找到某种方式将两者关联起来。如果你能做到这一点，你的问题就解决了，因为你可以像以前一样继续使用电话桌。

将新表与旧位置表相关联将帮助您获取电话号码之外的信息