假设我的数据库跟踪鸟类的踪迹（注意：我正在刮取桶底部的例子）。
字段是：
sighting_id | common_name | park_name | location | time | etc....
虽然我假设公园总是在同一个地方，但网站就像一个电子表格。用户为每个条目输入park_name和location。另请注意，我的实际架构还有其他字段，这些字段也依赖于类似的“公园名称”（例如州）。
我没有办法让用户预定义公园，所以我不能提前知道它们。我是否应该尝试动态规范化这些数据？例如，我的程序是否应自动填充parks表，用park_id替换鸟类目击表中的park_name和location列？
我主要担心表现。列出每个目击都需要一个连接来填充公园和位置。此外，动态管理这几乎肯定需要比保存更多的资源。我可能需要一个Cron工作来消除孤儿公园，因为它们可能被多次目击引用。
答案 0 :(得分：3)
这取决于您的使用情况。规范化方法（park是一个表）将使以下查询更容易：
但是，你确实遇到了一些棘手的问题。模式“如果公园XYZ不存在然后将其插入公园表”，则会遇到您必须处理的竞争条件。
现在，这里反对规范化的一些论点怎么样......大多数客户数据库可能会将我的街道地址存储为“123 Foo Street”，而不会动态规范化街道名称（我们可以有一个街道表并将“Foo Street”放在那里然后从其他表中引用它。为什么我提出这个问题，以表明即使是那些讨厌任何重复数据的人也可能会承认有一些你不一定要跨过的行。
另一个愚蠢的例子是我们可能会分享姓氏。我们真的需要一个表来获取唯一的姓氏，然后从其他表中获取外键吗？可能有一些应用程序对这有帮助，但99％的应用程序在那里，这太过分了。这只是更多的工作而且性能更差，几乎没有收获。
所以我会考虑如何从表中查询数据。老实说，在这种情况下，我可能会为公园单独制作一张桌子。但在其他情况下，我选择不这样做。
这是我的两分钱，税后一分钱。
答案 1 :(得分：2)
关于原始“公园”示例的两分钱（与OP的实际问题相对）：
反对尝试自动规范化公园和位置列的决定性论点是可用性：当数据以可编辑的电子表格格式呈现给用户时，他们自然会假设每行都可以独立编辑，如果某些列（例如“location”）实际上与公园相关联而非行，则它具有欺骗性（并且可能最终导致混淆）。
处理此类情况的典型模式是仅在提示公园的详细信息时提示用户，并在输入新公园时在“公园”表格中创建一行。例如，如果公园列包含下拉框，则最后一个选项可以是“添加新公园”。或者，当用户输入无法识别的公园名称时添加新公园 - 但仍然向用户说明正在创建新公园。