inheritance - 使用 NHibernate 从数据库填充大树时的表每个子类策略

标签 inheritance nhibernate table-per-class

我正在使用 NHibernate 加载不同类型的对象的大树。映射是使用 table-per-subclass 策略实现的。我定义了一个基类“Node”,它只有几个字段(NodeId、ParentId、NodeType)和几个从 Node 继承并添加自己的字段的子类。

这种方法的实现很简单,我不能提示性能。使用一次往返,在几百毫秒内在我的旧机器上填充了一个包含 10 000 个不同类型对象的大树。然而,有一件事情让我担心:这种策略会导致生成一个复杂的查询,其中 Node 表与对应于定义的子类的每个其他表进行外部连接。虽然当不同子类的数量很少时这很好,但如果数量增加,则 OUTER JOIN 复杂度也会增加。

为每个类定义表似乎不是一个优雅的选择,并且从基类中选择数据时它会运行缓慢(因为 UNION)。其他选项似乎会增加到数据库服务器的往返次数。

那么在填充由不同类型的实体组成的大树时,您认为什么是最佳实践?有什么比每个子类的表更好的吗?

最佳答案

你在这里处理两个问题:

  • 遍历一个大的层次结构。
  • 大对象图。

  • 两者都是 ORM 会遇到麻烦的领域。 ORM 将成为这里的瓶颈,因此当您遇到瓶颈时,您可能需要回避标准 ORM 功能并使用存储过程来处理繁重的工作。

    使用存储过程,您可以利用 SQL 的执行计划来解决问题、识别查询慢点并识别索引机会。

    From the Nhibernate Documentation (This is a cache Nhibernate Forge was down)

    Use hand-coded ADO.NET in bottlenecks.

    In performance-critical areas of the system, some kinds of operations (eg. mass update / delete) might benefit from direct ADO.NET. But please, wait until you know something is a bottleneck. And don't assume that direct ADO.NET is necessarily faster. If need to use direct ADO.NET, it might be worth opening a NHibernate ISession and using that SQL connection. That way you can still use the same transaction strategy and underlying connection provider.

    关于inheritance - 使用 NHibernate 从数据库填充大树时的表每个子类策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1868359/

    相关文章:

    java - 具有不同主键的 Hibernate 继承

    c++ - 没有在所有子类中使用虚函数的参数;有什么更好的设计方法吗?

    python - 如何设置一个具有所有方法和功能的类,如内置的 float,但保留额外的数据?

    c# - Fluent nHibernate - 映射字符串列表

    c# - 将公式映射到 IEnumerable bycode

    mysql - Nhibernate 选择日期部分

    c# - Entity Framework TPC 外键关系

    javascript - MDN 标题为 "Object.create()"的文档中关于 javascript 继承的混淆

    javascript - 使用 Selfish 在 Javascript 中实现简单继承