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

Question

经过与同事的几次讨论后，我们对这个话题仍然没有相同的含义。

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

我认为的优点
  - 由于数据库中的关系冲突，没有“错误”插入   - 数据库和程序严格分离   - 同一数据源的几个程序需要较少的工作来定制
  - 更容易使用LINQ   - 还有更多......？

这种方式可能有什么缺点？
不相关的表有什么好处？

Answer 1

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

Answer 2

事务系统应“始终”将参照完整性强制执行，尽可能靠近数据库。大多数人都同意这最好在数据库内部完成。您已正确认识到让DBMS强制执行参照完整性的许多优点。

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

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

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

有时不使用参照完整性的另一个原因是归档旧的事务数据可能会因主表和事务表之间复杂的相互关系而变得棘手。您可以轻松地找到自己无法删除任何数据的位置，无论它有多大，因为它与某些与当前事物所需的其他事物相关的事物有关。

说完所有这些之后，你肯定应该从使用数据库的参照完整性功能的位置开始，如果你有一个非常好的，考虑周全，只能退出em>理由。