我正在考虑在一个项目上使用 NHibernate，该项目的数据库具有一定程度的计划非规范化（由 DBA 计划）。 从一组表中读取数据并将一列映射到一个属性不是问题。 但是，在更新时，我必须将一个属性映射回原始表中的原始列，并更新非规范化表中该列的一些副本。 是否可以在不使用存储过程的情况下使用 NHibernate 来完成此操作？
编辑：虽然我倾向于同意 NXC 的答案，但这个问题是关于如何使用 NHibernate 解决问题，而不是在数据库中解决问题。
I'm pondering the use of NHibernate on a project that has a database with some degree of planned denormalization (planned by the DBAs). Reading from one set of tables and mapping one column to one property is not a problem. However when updating I'd have to map one property back to the original column in the original table plus update a few copies of that column in the denormalized tables. Is it possible to do this with NHibernate without using stored procedures?
EDIT: Although I tend to agree with NXC's answer, this question is about how to solve the problem with NHibernate as opposed to solving it in the database.
发布评论
评论（2）
是的，您可以注册一个继承自 DefaultSaveOrUpdateEventListener 的事件侦听器，覆盖 OnSaveOrUpdate 并更新其他实体。
以下是一些有关事件侦听器的博客文章：
Yes, you can register an event listener inheriting from DefaultSaveOrUpdateEventListener, override OnSaveOrUpdate and update the other entities.
Here are some blog posts about event listeners:
关于非标准化数据的一些想法：
谨慎使用； 众所周知，过度使用非规范化数据是维护和数据质量问题的根源。 我参与的一个 J2EE 项目在 560 个表中只有 4 个非规范化数据项 - 其中两个是搜索表。
依赖应用程序来保持非规范化数据同步是一种已知的反模式。 在事务系统中维护非规范化数据的普遍接受的方法是使用数据库触发器。 使用触发器意味着来自任何来源（不仅仅是您的应用程序）的更新都将由数据库本身传播。 除非有特定的情况阻止，否则最好使用触发器来维护非规范化数据。
非规范化数据给维护开发人员留下了大象陷阱（特别是如果您不使用数据库触发器来维护数据）。 确保记录每一条非规范化数据。
Some thoughts on de-normalised data:
Use sparingly; excessive use of denormalised data is known to be a source of maintenance and data quality problems down the track. One J2EE project I was involved in had just 4 denormalised data items in 560 tables - two of those items were search tables.
Relying on an application to keep de-normalised data in sync is a known anti-pattern. The generally accepted way to maintain de-normalised data in a transactional system is to use database triggers. Using triggers means that an update from any source (not just your application) will be propogated by the database itself. You would be better off using triggers to maintain the denormalised data unless something specific prevents it.
Denormalised data leaves elephant traps for maintenance developers (especially if you don't use DB triggers to maintain the data). Make sure each and every piece of denormalised data is documented.