ORM和具有很多约束的现有数据库（特别是主键之外的唯一键约束/唯一索引）在数据库本身内实施的兼容性如何？
（通常这些是预先存在的数据库，由众多遗留应用程序共享。但良好的数据库建模实践是在数据库中定义尽可能多的约束，作为对应用程序的仔细检查。还要注意数据库引擎我是使用不支持延迟约束检查。）
我之所以要问的是，我所研究的ORM，NHibernate和Linq to SQL，在数据库唯一约束存在的情况下似乎并不是很好。例如，删除行并使用相同的业务键重新插入一行会导致外键异常。 （还有一些微妙的，更难以避免的例子。）ORM观察主键和外键约束，但往往忽略了唯一约束。
我知道有一些解决方法，例如NHibernate flush方法。但是，我觉得这是一个非常漏洞的抽象，并且很难设计关于分离关注点的应用程序。理想情况下，所有对象都可以通过子程序在内存中进行操作，然后主例程可以负责调用实际同步数据库。这会隔离更新并允许自定义逻辑在实际提交到数据库之前检查所有更新。
以正确的顺序执行命令并非易事。请参阅我的问题here。尽管如此，我期待更好地支持流行的ORM中的常见案例。这对于将ORM引入现有环境似乎非常重要。
您使用ORM技术的经验是关于这些问题的吗？
答案 0 :(得分：2)
这当然是恕我直言......
ORM通常将数据库视为仅作为数据的存储介质，并且旨在将约束/业务逻辑维持在“O”侧而不是“R”侧。我没有看到任何ORM产品使用一些更“硬核”的关系数据库概念，如备用密钥，复合唯一索引和独占子类型。从某种意义上说，ORM使数据库成为二等公民。
叫我老式，但是ORM似乎对阅读数据有好处，但是为了将数据写回到一个非平凡的关系设计中，我总是发现它不足。我更喜欢通过SQL和/或存储过程来完成所有更新。
答案 1 :(得分：0)
如果正确映射数据库，那么良好的ORM和NHibernate就是其中之一，将强制执行参照完整性和正确的订单执行。据我所知，它们都不支持检查或唯一约束。检查约束是应在业务对象中强制执行的业务规则。我通常只使用检查约束和/或触发器来强制执行关键业务规则（即，如果违反这些规则，业务会损失金钱和/或我会失去工作）。
唯一约束通常代表备用键。对于ORM，通常的做法是使用代理键（标识）作为主键，并对自然键强制执行唯一约束。 ORM实现唯一约束检查将是一项挑战，因为它需要在每次插入或更新之前进行选择和锁定。通常，最佳做法是始终在事务中执行操作，如果事务失败可以回滚，并向用户提供有意义的错误消息。
例如，删除行并使用相同的业务键重新插入一行会导致外键异常。
您是否尝试在单个ISession的范围内执行此操作？我可以看出这是有问题的。