Mysql 动态规范化表是否可行？

假设我的数据库跟踪鸟类目击事件（注意：我真的在抓拍桶底的例子）

这些字段是：

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

虽然我假设公园总是在同一个位置，但这个网站就像一个电子表格。用户为每个条目输入

park\u name

和

location

。另外请注意，我的实际模式还有其他字段，它们也依赖于类似的“公园名称”（例如state）

我没有办法让用户预先定义公园，所以我无法提前知道它们。我是否应该尝试动态规范化这些数据？例如，我的程序是否应该自动填充一个

parks

表，用

park\u id

替换观鸟表中的park\u name和location列

---

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

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

• 每个公园有多少鸟类目击
• 在哪个公园你最有可能看到鸟XYZ
• 可能还有很多类似的问题

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

现在，我们来看一些反对规范化的论点。。。大多数客户数据库可能将我的街道地址存储为“123 Foo street”，而不动态规范化街道名称（我们可以有一个街道表并放置“Foo street”）在这里，然后从其他表格中引用它。为什么我要提出这个，好吧，以表明即使讨厌任何重复数据的家伙也可能会承认，有一些线你不一定要跨越

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

<> P>所以我会考虑如何查询表中的数据。老实说，在这种情况下，我可能会为PARK做一个单独的表。但是在其他情况下，我不选择。< /P>

---

这是我的2美分，税后1美分。

我在最初的“公园”示例中的2美分（与OP的实际问题相反）：

反对尝试自动规范化park和location列的决定性论据是可用性（usability）：当数据以可编辑的电子表格格式呈现给用户时，用户自然会认为每一行都可以独立编辑，因此这是欺骗性的（并可能最终导致混淆）如果某些列（如“位置”）实际上与公园关联，而不是与行关联

---

处理此类情况的典型模式是，在输入新公园时，仅提示用户提供公园的详细信息，并在“公园”表中创建一行。例如，如果公园列包含下拉框，则最后一个选项可以是“添加新公园”。或者，当用户输入一个无法识别的公园名称时，添加一个新的公园——但仍然要向用户明确新公园正在创建。

这个“问题”似乎是从哪里冒出来的……应该（很可能）有一个

公园
表。即使两个公园（比如在不同的州）有相同的名称，它们也是两个不同的公园（如前所述）这一点应该被捕获。从一个好的模型开始——在分析并确定它是一个问题之前，不要担心性能。改善性能比修复坏数据和“好模型”更容易如果不是更快的话，在这里也会一样快。我不在乎公园是否一样：这些数据只会被显示，不会被执行。我的实际问题（这只是一个类比，但我意识到这不是很好）处理姓名、性别和大学栏。我不一定关心两个人是否有相同的姓名、性别等。我只是想知道不复制此数据是否值得。除非有经验证的测试用例，否则不值得。保存少量记录（所有字段恰好对齐）事实上，这将更难维持——一个人的名字（和性别）可以独立于其他人（因此是独立的实体）而改变。这是非常正确的。如果一个人的名字（或性别）更改后，查找所有实际使用的名称以删除孤立的名称是一个疯狂的过程。请注意，我已澄清了我的原始问题，并提出了这个衍生问题：@Matthew:谢谢你的见解：）。我的实际问题（如我所说，这只是一个类比）更接近你的“姓氏”表示例。我要处理的字段是name、sex和university。让我们看看。name可以存储在单独的表中，但这太差劲了。所以我们不需要对其进行动态规范化。sex我会使用类似枚举的列（值1,2）.出于风格的原因，避免将性别视为布尔值。现在，我会尝试对大学进行标准化，但这又取决于您如何进行查询。我将根据大学搜索行。我认为，如果我必须加入大学表，则该操作的效率将更低。如果您对大学进行标准化，您将拥有在用户进入您尚未拥有的大学时“及时”创建大学行。这是可行的，但处理竞争条件取决于一些部署条件。是否只涉及一个应用程序