Question

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

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        |

Answer 1

你是对的，应该只有一种方法来记录数据库中的每个事实，不应该允许重复的行。如果每一行代表特定开发中具有一定数量卧室的单元数量，则development_id, bedrooms上的唯一键是有意义的，并且将阻止每个开发中相同类型单元的多个条目。

Answer 2

有趣的是，你＆amp;后端同事/竞争对手都是对的。

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

根据您的揭示，不需要分成多行。虽然从现在开始想象它会从另一个属性中获得另一个属于另一个属性的属性。说，适当的计划。或者是时间戳，无论出于何种原因。它立即开始变得有意义。

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

虽然我远远没有想到你的房地产经纪人在他们的补充中会达到甚至一位数的TPS，所以你可能会认为一个规模不存在的问题。： - ）

存储相同数据的两种方法

2 个答案: