我的一个朋友在设计完数据库后正在创建一个应用程序。然而，她只是将所有内容放在两个1st-NF表中，这两个表对非PK列有一些函数依赖关系。事实上，在我建议她之后，她添加了PKs。她的系统的3rd+NF设计可能需要7到15张表。
我指出，会有几个可能的更新异常。然而，她表示，她已经存储了插入和更新的过程，因此更新异常永远不会发生，因为她将强制用户/应用程序通过存储过程插入/更新数据。
有没有其他好的理由说服她设计更高规范形式的系统？或者她的解决方案在实践中足够好吗？
她可能不熟练，也没有意识到这一点。人们已经证明，没有办法帮助这些人。
她可能认为她可以正确地获得SP中的所有代码，而不会犯任何错误。这不仅仅是对她自身能力的荒谬高估。
我建议你让她简单地犯错误。对你来说，这将节省尝试的时间和未能成功传达信息的沮丧情绪，对她来说，这也将给她从自己的错误中学习的机会（唯一的选择，因为她显然不愿意从别人的错误中吸取教训），这将使她免于沮丧，因为她不得不接受你以后的"我早就告诉过你了"
但如果你真的坚持要尝试一下，那么你可能会向她指出：
- 她的1NF表实际上是她不愿意实现的3/BC NF表上的视图（具体化的视图）
- 然而，她的最终用户可能期望进行的更新最有可能是对7-15 3/BC NF表的更新。（我这么说是因为你指出，作为她降低NF的唯一原因，她想避免如此"巨大"的桌子数量——"巨大"中的冷嘲热讽是故意的。）
- 但是DBMS期望的更新是对1NF表（其是视图）的更新
- 因此，她的问题归结为"从指定为3NF表视图更新的更新中提取出对3NF表的适当更新"
- 因此，让她所有的SP代码都是正确的，这是一个如何进行视图更新的问题
- 你猜怎么着，经过40多年对关系模型的研究，成千上万的研究人员的智力可能比她高出几个数量级，正是这个观点更新的问题仍然没有解决。。。（尽管这是理所当然的，但她的问题不是"一般情况下的视图更新"，而是"在特定情况下更新视图"。尽管如此，我非常怀疑她是否有能力发现所有涉及的复杂性。）