在这种情况下,非规范化是否可接受？

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

My opinion, for what it's worth, is that de-normalisation is something you do to gain performance if, and only if, you actually have a performance problem. I always design for 3NF and only revert if absolutely necessary.

It's not something you do to make your queries look nicer. Any decent database developer would not fear a moderately complex SQL statement although I do have to admit I've seen some multi-hundred-line statements that gave me the shivers - mind you, these were from customers who had no control over the schema: a DBA would have first re-engineered the schema to avoid such a monstrosity.

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

我能看到的直接限制(可能还有其他限制)是:

• 您将被限制(最初,没有架构更改)到每个位置五个电话号码.根据您的描述,您似乎不会将此视为问题.
• 你将浪费空间存储不必存在的数据.换句话说,每行使用五个数字的空间而不管它们实际具有什么,尽管这种影响可能很小(例如,如果它们是varchar和可空的).
• 查询电话号码的查询将会很复杂,因为您必须检查五个不同的列.这是你的一个用例,我不知道,所以它可能是无关紧要的.

你可能应该选择其中一种方式(我不确定这是不是你的意图).如果我遇到一个在商店桌面和单独的电话号码表中都有电话号码的架构,我会特别恼火,特别是如果他们彼此不同意的话.即使我取消规范化,我也倾向于使用插入/更新触发器来确保数据的一致性.