处理服务器端或程序中的数据库关系

Question

与同事进行了几次讨论之后，我们对这个主题的意义仍然不同。

在我看来，创建一个包含所有关系的设计正确的数据库更有意义。我在这方面并没有真正的经验，这就是为什么我要问你。在我看来

优势
- 因为在数据库中的关系冲突的任何“错误”插入
- 数据库和程序是严格分隔
- 一些programms的为同一数据源需要更少的工作来定制
- 使LINQ的使用更容易
- 还有更多....？

这种方式可能存在哪些缺点？
不相关的表的优点是什么？

Answer 1

交易系统应该“始终”使参照完整性尽可能接近数据库。大多数人会同意这最好是在数据库本身内完成。您已经正确认识到让DBMS强制执行参照完整性的许多优点。

我之所以说“总是”，是因为我相信常识和慎重的决定，而不是经验法则。

有人可能不希望在数据库中强制执行参照完整性的一个原因是，您有一个循环关系，父母和孩子需要相互指向，并且由于另一个记录不可能插入一条记录还没有。这给你留下了一个所谓的catch-22。在这种情况下，您可能需要在程序逻辑中强制执行参照完整性。尽管如此，最好的地方是数据层，而不是应用层。

有些人不担心引用完整性的另一个原因是数据是只读的。这可能发生在报告数据库或数据仓库中。数据库中的参照完整性会创建用于执行关系的索引。这有时会成为空间问题，但更多的时候，由于所需的操作顺序使得数据仓库更难加载，这只是一个问题。

为什么引用完整性有时使用而不是的另一个原因是由于主表和事务表之间存在复杂的相互关系，归档旧事务数据会变得棘手。你可以很容易地发现自己处于一个不可能删除任何数据的位置，不管它有多大，因为它与某种事物相关，而这些事物与当前所需的另一件事有关。

说了这一切，你一定要使用你的数据库的引用完整性功能的位置开始，仅背部离开这，如果你有一个很好的，充分考虑原因。

Answer 2

当然!!!您必须在数据库模型中强制引用完整性！更安全，更高效，保证数据完整性，而且您不依赖程序员。这里没有讨论。
例如，如果您只是建立一个可以从各种系统下载夜间数据的“报告数据库”，则不会使用相关表格。