我应该与数据库架构建立关系还是以编程方式处理它们？
例如当我在MSSQL中构建数据库时，我不能构建关系并以编程方式处理关系，例如检查密钥是否作为另一个表中的主键存在，并确定将新行插入到是否表。
任何人都可以告诉我这是不是一个好习惯。
答案 0 :(得分：2)
DO 通过声明外键约束来明确表之间的关系。
我认为没有任何理由不这样做。为什么外键约束是个好主意？
外键约束是帮助保护数据完整性/一致性的简单方法。
约束（不仅仅是外键）也可以看作是“活文档”的一种形式（使事物变得明确，因此可以被发现，而不必猜测）。
您可能仍希望在代码中验证插入内容;在这种情况下，如果您的代码失败，您可以将外键约束视为“安全网”。
（关于上面的第二个要点：我必须使用一个遗留数据库，这个数据库缺少一些外键约束，应该通过各种方式声明。这意味着每次我必须对其进行更改时，我可能无意中破坏了一个应用程序，该应用程序通过查看模式对模式做出某些假设是不明显的。使用这个数据库非常痛苦且容易出错。如果我可以改变这个数据库的一件事，那就是添加所有缺失的约束。）
答案 1 :(得分：0)
这取决于你的需要。 如果您正在设计OLTP应用程序，那么构建关系是好的，但如果您设计数据仓库DWH或datamart，则建议不要在架构中建立关系并在代码中处理它。