ORM和数据库约束

Question

ORM和现有数据库在数据库本身内强制执行有多少约束（特别是主键之外的唯一键约束/唯一索引）兼容性如何兼容？ （通常这些是已有的数据库，由许多传统应用程序共享）但是良好的数据库建模实践是在数据库中定义尽可能多的约束作为对应用程序的双重检查另外请注意，数据库引擎I我正在使用不支持延迟约束检查。）

我问的原因是我已经研究过的ORM，NHibernate和Linq to SQL，在数据库唯一性限制。例如，删除一行并重新插入具有相同业务关键字的行会导致外键异常。 （有些微妙，难以避免的例子。）ORM观察主键和外键约束，但往往忽略了独特的约束。

我知道有一些解决方法，比如NHibernate的flush方法。但是，我觉得这是一个非常漏洞的抽象，并且很难设计关于分离问题的应用程序。理想情况下，所有对象都可以通过子程序在内存中进行操作，然后主例程可以负责实际同步数据库的调用。这隔离了更新并允许自定义逻辑在实际提交到数据库之前检查所有更新。

以正确的顺序执行命令是非平凡的。看到我的问题here。尽管如此，我期待对流行的ORM中的常见病例有更好的支持。这对于将ORM引入现有环境看起来非常重要。

使用ORM技术的经验是什么？

Answer 1

这当然IMHO的...

ORM一般对待数据库作为仅用于数据的存储介质和朝向保持在所述“O”侧的约束/业务逻辑，而不是“R”面向侧。我还没有看到任何使用一些更“硬核”关系数据库概念的ORM产品，例如备用密钥，复合唯一索引和独占子类型。从某种意义上说，ORM使数据库成为二等公民。

打电话给我老式的，但ORM似乎很适合阅读数据，但为了将数据写回非重要的关系设计，我总是发现它不够用。我更喜欢通过SQL和/或存储过程来完成所有更新。

Answer 2

好的ORM和NHibernate是一个，如果数据库映射正确，将强制执行参照完整性和正确的命令执行。据我所知，他们都不支持检查或独特的约束。检查约束是应该在业务对象中执行的业务规则。我通常只使用检查约束和/或触发器强制实施关键业务规则（即业务会亏本，和/或如果违反这些规则，我会失去工作）。

唯一约束通常代表一个备用关键。对于ORM，通常使用代理键（标识）作为主键，并对自然键实施唯一约束。 ORM实施独特的约束检查将是一项挑战，因为它在每次插入或更新之前都需要选择和锁定。通常，最佳做法是始终在事务中执行操作，如果事务失败并可向用户提供有意义的错误消息，则该事务可以回滚。

例如，删除一行并重新插入具有相同业务关键字的行会导致外键异常。

你是否试图在单个ISession的范围内做到这一点？我可以看到这是有问题的。