3

假设我的数据库跟踪鸟类观察（注意：我真的在刮桶底部的例子）。

这些字段是：

sighting_id | common_name | park_name | location | time | etc....

虽然我假设公园总是在同一个位置，但该网站就像一个电子表格。用户输入park_name和location为每个条目。另请注意，我的实际模式还有其他依赖于类似“公园名称”的字段（例如状态）。

我没有办法让用户预定义公园，所以我无法提前知道它们。我是否应该尝试动态规范化这些数据？例如，我的程序是否应该自动填充一个parks表，将观鸟表中的 park_name 和 location 列替换为park_id?

我主要担心性能。列出每个目击事件需要一个连接来填充公园和位置。此外，动态管理这几乎肯定需要比它节省的更多资源。我可能需要一个 Cron 工作来消除孤儿公园，因为它们可能会在多次目击中被引用。

4

2 回答 2

3

这取决于您的使用情况。规范化方法（park 是一个表）将使以下查询更容易：

  • 每个公园有多少鸟类目击事件
  • 你最有可能在哪个公园看到鸟 XYZ
  • 可能还有很多这样的查询

但是，是的，您确实遇到了一些棘手的问题。“如果 park XYZ 不存在，则将其插入 parks 表中”的模式受到您必须处理的竞争条件的影响。

现在，这里有一些反对规范化的论据怎么样......大多数客户数据库可能将我的街道地址存储为“123 Foo Street”，而没有动态规范街道名称（我们可以有一个街道表并将“Foo Street”放在那里，然后参考我为什么要提出这个问题，以表明即使是讨厌任何重复数据的人也可能会承认有些线您不一定要跨越。

另一个愚蠢的例子是我们可能共享姓氏。我们真的需要一个表来存储唯一的姓氏，然后从其他表中获取外键吗？可能有一些应用程序会有所帮助，但对于 99% 的应用程序来说，这太过分了。这只是更多的工作和更少的性能，几乎没有收益。

所以我会考虑如何从表中查询数据。老实说，在这种情况下，我可能会为公园制作一张单独的桌子。但在其他情况下，我选择不这样做。

那是我的两分钱，税后一分钱。

于 2011-06-11T22:16:32.437 回答
2

我对原始“公园”示例的两分钱（与 OP 的实际问题相反）：

反对自动规范化 park 和 location 列的决定性论据是可用性：当数据以类似电子表格的可编辑格式呈现给用户时，他们自然会假设每一行都可以独立编辑，因此它具有欺骗性（并且可能最终导致混乱）如果某些列（例如“位置”）实际上与公园相关联，而不是与行相关联。

A typical pattern for handling this sort of situation is to only prompt the user for park's details and create a row in the "parks" table when a new park is entered. For example, if the park column contains a drop-down box, then the last option could be "add new park". Alternatively, add a new park when the user enters an unrecognized park name -- but still make it clear to the user that a new park is being created.

于 2011-06-12T00:20:12.090 回答