database - 关系型RDBS的低范式数据库设计

Question

我的一个 friend 在设计数据库后正在创建一个应用程序。但是，她只是将所有内容都放在两个 1st NF 表中，这些表对非 PK 列有一些功能依赖性。确实，她在我建议她之后添加了 PK。她的系统的 3rd+ NF 设计可能需要 7 到 15 个表。

我指出可能会有几个更新异常。不过，她说她有插入和更新的存储过程，所以更新异常永远不会发生，因为她会强制用户/应用程序通过存储过程插入/更新数据。

还有什么其他好的理由可以说服她设计更高范式的系统吗？或者她的解决方案是否足够好？

Answer 1

她可能不熟练，没有意识到这一点。事实已经证明，没有办法帮助这些人。

她可能认为她可以正确获取那些 SP 中的所有代码，而不会犯任何错误。这不仅仅是对她自己能力的可笑高估。

我建议你让她简单地犯错误。对你来说，这将节省尝试的时间和未能成功传达信息的挫败感，而对她来说，这将让她有机会从自己的错误中吸取教训(唯一的选择，因为她显然不太愿意学习从其他人的错误中)，这将使她免于经历你后来带着光荣的“我告诉过你”的挫败感。

但如果你真的坚持要试一试，那么你可能会向她指出:

• 她的 1NF 表实际上是她不愿意实现的 3/BC NF 表的 View (当时的物化 View )。
• 她的最终用户可能希望进行的更新很可能是对那些 7-15 3/BC NF 表的更新。 (我这样说是因为你表示她想要避免如此“庞大”的 table 数量是她降低 NF 的唯一原因——“巨大”中的玩世不恭是故意的。)
• 但 DBMS 期望的更新是对 1NF 表(即 View )的更新。
• 因此，她的问题归结为“从指定为对这些表的 View 更新的更新中提取对 3NF 表的适当更新”。
• 因此，让她所有的SP代码都正确，就是一个如何进行 View 更新的问题。
• 你猜怎么着，经过 40 多年的关系模型研究，成千上万的研究人员的智力可能比她高出几个数量级，正是这个 View 更新问题仍然悬而未决......(虽然理所当然，但她的问题不是“一般的 View 更新”，而是“在某些特定情况下的 View 更新”。尽管如此，我非常怀疑她是否有能力发现所涉及的所有复杂问题。)