Hibernate策略脱机获取多个表？

听起来很疯狂，但故事是这样的

背景：

• 想象一下，我们的数据库是这样的：公司有n名员工，他们有配偶和孩子。员工也有带轮胎的汽车……等等
• 我们的应用程序同时提供Web和桌面UI。因此，用户希望从多个表加载数据，以便在桌面上脱机工作。例如：将大约1000家公司加载到桌面上进行工作
• 数据量很大，从数千条记录到数十万条记录不等。但是离线加载的数据并没有那么大，只有几千个

当前架构：

• 我们正在使用，非常类似于DAO，例如对于每个实体，我们都有一个汇编器。但是对Hibernate的访问非常有限
• 对于Web，我们使用延迟加载，到目前为止还不错
• 对于AIR desktop，我们正在尝试许多选项

AIR desktop的选项，请注意实体都标记为惰性，我们考虑以下选项之一：

在命名的hql中使用“fetch join”：将公司、员工、汽车、轮胎一起装入一个hql中

分别加载每个表，然后手动匹配它们

使用带BatchSize的即时获取？！！难以控制

放弃Hibernate，回到大型JDBC查询

请给我们你的建议。谢谢

如果您有多个1-N关系，那么返回的结果集将包含太多冗余数据，以我的经验，Hibernate处理起来会太慢

我会使用Hibernate或普通SQL来实现这一点。实际上，Hibernate可以在一定程度上做到这一点，方法是注释您与@Fetch（FetchMode.SUBSELECT）的关系。 例如，当您根据条件检索某些公司时，将运行以下SQL：

SELECT * FROM company WHERE condition
SELECT * FROM employee WHERE employee.company_id IN (SELECT id FROM company WHERE condition)

但请注意，这只在某些数据库中有效。如果性能不好，考虑第3类。

我在这种情况下尝试过BatchSize，它在一定程度上提高了性能，但选项2更好

它可以归结为SQL运行。如果这是有效的，Hibernate通常不会增加那么多开销（只会增加对象创建的开销，将所有对象保留在内存中，等等）

---

谢谢，我还在努力。我对你的答案很满意，但让我们看看其他人的想法经过多次测试，我们决定选择：@Fetch（FetchMode.SUBSELECT）它节省了很多性能。然后根据具体情况，它可以是懒惰的，也可以是渴望的。与#1结合使用是很好的。关于选项2，“一定程度”是什么意思？这是否意味着它在某些情况下不起作用？它肯定会起作用，但是它可能不会为特定数据库提供最佳性能（in子句with subquery并不总是快速的，取决于数据库）