最佳实践：我应该在使用 nHibernate/FluentNhibernate 的数据库上使用 FK 吗？
到目前为止，我总是强制我的 DB 与 FK 关系。昨天在使用 FluentNhibernate 映射一些类时情况发生了变化。我的映射不起作用，我发现问题在于 FN 创建查询的顺序。
现在出现了一个问题：我应该继续使用 FK 强制执行数据，还是最好避免它，因为我专注于域类而不是 sql 查询？
谢谢
So far I always enforce my DB with FK relationship. Things changed yesterday while mapping some classes with FluentNhibernate. My mapping didn't work and I discovered that's the issue was because of the order FN create the query.
Now a question arise: should I keep enforcing data with FK or it's better to avoid it since I focus on domain classes instead of sql queries?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
据我所知，保持数据库一致会更好，
因为你将来可能不是唯一一个在这个数据库上工作的人，
也许其他人可以访问数据库并执行可能会破坏您的数据一致性的操作
因此，由于假设的条件不再成立，您的应用程序也不会按照您期望的方式运行。
To my knowledge, it will be far better to keep your database consistent,
cause you may not be the only one who works on this DB in future,
and maybe someone else have access to the DB and do sth that could corrupt your data consistency
and as a result your application also doesn't behavior in the way you expect because of assummed conditions that no longer hold.
让 Fluent/NH 在开发期间创建数据库很好，但是当它投入生产时，您确实应该检查所有外键、索引等，然后只在之后进行脚本化更改。
Letting Fluent/NH create your database during development is fine, but when it goes into production you really should check all the foreign keys, index's, etc etc and then only do scripted changes there on after.
保持数据库一致，保持引用完整性。
如果您使用的工具因此而损坏，必然有解决方法。但是，如果您因使用 nhibernate 而失去引用完整性 - 如果您决定使用不同的 ORM，会发生什么情况？您将拥有一个不可靠的数据库，谁能保证下一个 ORM 会喜欢这样呢？
这就像一个关注点分离问题，应用程序的每个块都应该设计得足够健壮，以便在另一个块被更改或删除时仍然可以生存 - 因此，不要仅仅为了制作分层在其之上的产品而改变良好的数据库实践玩得好。
Keep your database consistent, maintain referential integrity.
If a tool you are using breaks as a result there is bound to be a workaround. However if you lose referential integrity to use nhibernate - what happens if you decide to use a different ORM? You will have a dodgy database and who's to say that the next ORM in line will like that?
Its like a separation-of-concerns question, each chunk of your application should be designed to be robust enough to survive if another chunk is changed or removed - so don't change good database practice simply to make a product that is layered above it play nicely.
使用领域驱动方法或面向模型的方法（其中数据库仅被视为“实现细节”）并不意味着您应该忽略数据的完整性。
我认为没有理由应该从数据库中删除外键（和其他）约束。
数据库不仅仅是数据的存储。它的任务也是维护其完整性。
NHibernate 完全有可能将这两个世界（领域驱动和关系数据库）结合起来。确保这两个领域专注于他们最擅长的领域。而且，数据库最擅长存储数据并确保数据保持有效/整数。
Using a domain-driven approach , or model oriented approach where the DB is merely seen as an 'implementation-detail', does not mean that you should ignore the integrity of your data.
I see no reason why you should drop foreign-key (and other) constraints from your database.
The database is more then just a storage for your data. It's task is also to guard the integrity of it.
It is perfectly possible to combine the 2 worlds (domain driven and relational database) with NHibernate. Make sure that the 2 areas focus on what they're best at. And, the database is best at storing data and making sure that the data remains valid / integer.