两种存储相同数据的方法答案

【问题标题】：Two ways to store the same data两种存储相同数据的方法
【发布时间】：2017-01-28 07:38:06
【问题描述】：

在工作中，我们正在创建一个表单，以允许房地产经纪人提交他们的新开发项目。我们的表单的简化版本如下：

Bedrooms: [Enter a number]
Quantity: [Enter a number]

Add Another | Save

我们允许代理添加多行。然而，目前我们对重复项的验证绝对为零，我认为这允许我们的数据库以两种方式存储相同的数据：

| development_id | bedrooms | quantity |
|----------------|----------|----------|
| 1              | 3        | 1        |
| 1              | 3        | 1        |
| 1              | 3        | 3        |

显然，一行可以代表一个单位或组单位。

我的观点是，我们应该以另一种方式存储开发成果，但当然不能同时存储这两种方式。不幸的是，后端开发人员——我主要是前端——认为这没什么大不了的，对我来说这似乎很荒谬。

举个简单的例子，通过上面的存储，COUNT 来获取有多少有 3 间卧室的开发项目在出售，需要 SELECT COUNT(*) 和考虑 quantity字段。

作为前端开发人员，它似乎主要是表示逻辑，因为在将它们呈现为单个单元列表或将它们组合在一起之间进行转换应该是前端/API 任务，而业务逻辑应该是一个方式或其他。最终我们的表格似乎根本没有标准化。

依我的拙见，development_id, bedrooms 上应该有一个唯一索引。

我的论点正确吗？还是大错特错？

编辑：

澄清一下，所有这些目前都是可能的，所有这些都代表相同的事实，我的论点是应该只有一种方式：

| development_id | bedrooms | quantity |
|----------------|----------|----------|
| 1              | 3        | 1        |
| 1              | 3        | 1        |
| 1              | 3        | 1        |

同：

| development_id | bedrooms | quantity |
|----------------|----------|----------|
| 1              | 3        | 1        |
| 1              | 3        | 2        |

同：

| development_id | bedrooms | quantity |
|----------------|----------|----------|
| 1              | 3        | 3        |

【问题讨论】：

你是对的，应该只有一种方法可以在数据库中记录每个事实，并且不允许重复行。不过，我不确定您的唯一索引。 development_id 是做什么用的，当您有多行具有相同的值时，这意味着什么？
好吧，我们还有一个主要的id，所以它更像是：id (pk) | development_id (fk) | bedrooms | phase | floor_area | price | quantity，但简单的事实仍然是不应该有重复 - 对development_id, bedrooms, phase, floor_area, price 有一个唯一的约束。跨度>
“很明显，一行可以代表一个单元或一组单元。”我不清楚，我不明白。也不是“两种方式”。
对不起，划掉“两者”这个词。我将更新我的问题以澄清问题，基本上数据库能够记录具有不同表示的相同事实，正如@reaanb 指出的那样。
对不起，我没有关注...在我看来，索引应该在 development_id, bedrooms, quantity 上，否则我们会记录重复项。开发人员可以添加具有不同卧室的第二个单元。

标签： database database-design

【解决方案1】：

您是对的，应该只有一种方法可以在数据库中记录每个事实，并且不应允许重复的行。如果每一行代表特定开发项目中具有一定数量卧室的单元数量，那么development_id, bedrooms 上的唯一键是有意义的，并且将防止每个开发项目中同种单元的多个条目。

【讨论】：

【解决方案2】：

有趣的是，您和后端同事/竞争对手都是对的。

这没什么大不了的，真的（在所示情况下）。虽然它确实违反了数据库规范化（在所示情况下）。

根据您的披露，没有必要分成多行。虽然想象一下，从现在开始，它获得了另一个区别于另一个三床的属性。说，恰当的计划。或时间戳，无论出于何种原因。然后它立即开始有意义。

这里还有一件事：读取通常是非阻塞的，而写入是。这意味着，在具有行级锁的成熟 RDBMS 上，插入（和对 COUNT 的读取）不会竞争，而对计数器的更新会。

虽然我认为您的房地产经纪人组合起来可能会在他们的添加中达到甚至个位数的 TPS，但您可能会认为一个规模不存在的问题。 :-)

【讨论】：