我的一个朋友在设计数据库之后正在创建一个应用程序。不过，她只是将所有内容放在两个第一个nf表中，这两个表对非pk列有一些函数依赖关系。事实上，我推荐她之后，她又加了PKS。她的系统的3rd+nf设计可能需要7到15个表。
我指出会有一些可能的更新异常。不过，她说，她有用于插入和更新的存储过程，因此不会发生异常更新，因为她将强制用户/应用程序通过存储过程插入/更新数据。
有没有其他好的理由说服她设计更高标准形式的系统？或者她的解决方案实际上足够好吗？
最佳答案
她可能不熟练，对此一无所知。已经普遍表明，没有办法帮助这些人。
她可能认为她可以正确地获取这些SP中的所有代码，而不会犯一个错误。这不仅仅是对她自己能力的荒谬高估。
我建议你让她简单地犯错误。对你来说，这将节省尝试的时间和未能成功传达信息的挫败感，对她来说，这将给她从自己的错误中学习的机会（唯一的选择，因为她显然并不真正愿意从别人的错误中学习）。这样她就不用再沮丧了，因为她不得不忍受你后来带着那句光荣的“我早就告诉过你了”。
但如果你真的坚持要试试，那么你可以向她指出：
她的1nf表实际上是3/bc nf表上的视图（具体化视图），她不愿意实现这些视图。
然而，她的最终用户可能希望进行的更新最有可能是那些7-15 3/bc nf表的更新。（我之所以这么说，是因为你指出了她降低nf的唯一原因，即她希望避免出现这么多的表，“‘巨大’中的玩世不恭是故意的。）
但是dbms期望的更新是1nf表（视图）的更新。
因此，她的问题归结为“从指定为对这些表的视图的更新中提取对3NF表的适当更新”。
因此，让她的所有sp代码都正确，是一个如何进行视图更新的问题。
猜猜看，在对关系模型进行了40多年的研究之后，成千上万的研究者的智力可能超过了她的数量级，正是这个观点更新的问题仍然没有解决……（虽然她同意，但她的问题不是“一般的视图更新”，而是“某些特定情况下的视图更新”。尽管如此，我还是非常怀疑她是否有本事找出其中的所有错综复杂之处。）
关于database - 关系RDBS的低范式数据库设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/8936880/