Hibernate 查找表：作为对象关系或作为代码/键

Question

因此，我正在开发一个包含大量关系和查找表的应用程序，但这一切都归结为：

Person

id INT (PK)
... (name, address, etc)
optcode VARCHAR (FK to Options)
typecode VARCHAR (FK to Types)

Options

optcode VARCHAR (PK)
optdesc VARCHAR
... (more meta data, like date added, etc)

Types

code VARCHAR (PK)
desc VARCHAR
... (more meta data, like date added, etc)

I我正在使用 hibernate 来访问这些表，一方面，对象关系有好处，但另一方面，仅使用字符串来编写代码效果更好。

对象关系、键和两者哪个更好？

仅使用键：

public class Person {
     private int id;
     ... (more attributes)
     private String optcode;
     private String typecode;
}
In the services:
Person person = new Person();
person.setOptcode("ABC");
person.setTypecode("XYZ");
session.save(person);

或 O/R 方式：

public class Person {
     private int id;
     ... (more attributes)
     @JoinColumn
     private Options option;
     @JoinColumn
     private Types type;
}
In the services:
Person person = new Person();
person.setOption(new Options("ABC")); //Assume constructor fills in the 'optcode'
person.setType(new Types("XYZ"));     //Same, with 'code'
session.save(person);

在大多数持久性情况下，我只有“代码”，但很多时候在显示数据时，显示“描述”会很好，

因为我将有一个地方可以管理选项和类型实体，这些实体无论如何都会存在，但必须将“代码”包装在对象中只是很烦人。

您认为不同方式的优点/缺点是什么？如果我只是将两者都放入 Person 对象中，这样我就可以使用更方便的那个了，会怎么样？如何制作仅将字符串推入新的选项/类型实体的设置器？

我正在尝试确定最佳方法，以便保持一致，现在我只是在做任何需要最少数量新实体的事情，但最终所有内容都将由休眠实体表示。

更新： Person 实体最终将拥有近 20 个唯一的实体关系（每个实体关系都指向不同的表），Web-ui 可能会有包含每个表的值的下拉列表，因此我希望我只有用于持久性的“代码”。 相关：我实际上使用的是 PersonImpl（普通 POJO）和 PersonEntity（Hibernate Entity）以及 Dozer 映射之间的关系。

Answer 1

ORM 的全部意义在于为您提供一个对象图，您可以在其中导航，并映射到关系数据库。您应该能够使用 person.getOption().getDescription() 从人员那里获取其选项描述。

您还应该能够使用给定选项日期来搜索人员。

select p from Person p where p.option.date = :date

这只有在将外键映射为关联而不是字符串时才可能实现。

不过，您不应该使用 new Option(code) 将现有选项放入您的用户中。相反，您应该从会话中获取或加载选项：

Person p = new Person();
p.setOption((Option) session.load(Option.class, "ABC"));
p.setType((Type) session.load(Type.class, "XYZ"));
session.save(p);

// and now, this code works as expected:
System.out.println(p.getOption().getDescription());

Answer 2

我认为实体关系使您的编码更容易，一般来说，尤其是在查询对象时：有什么比说 person.getOption().getDescription() 更容易？然而，这种方法确实有缺点：

• 必须从数据库加载引用的实体，特别是当您有保存级联时。在保存级联中，您可能知道，Hibernate 会抱怨数据库中存在该对象。我不确定当你没有保存级联时会发生什么。
• 引用的实体必须使用单独的查询或在加载主实体时使用外部联接来加载。 可能导致性能问题。

将键保留为纯粹的属性可以在复杂关系的情况下有所帮助，例如，当引用一个需要由 Hibernate 完成大量负载的大实体时。这种方法可以帮助系统更轻松地加载“主”实体。这确实意味着如果您需要实体的属性，您将必须自己加载实体。我想说，对于不可变的“查找”类型实体，您可以安全地保留其实例的内存映射并通过其密钥 get() 它们，而不是访问数据库。缺点是您将划分实体处理逻辑：您必须记住要缓存哪些实体并管理它们的缓存。

我想说，一般来说，与实体合作总是更好，毕竟这是你的模型。 Hibernate 坚持指出它可以帮助你持久化你的对象模型来帮助你。那么将尽可能多的持久性工作委托给 Hibernate 是合乎逻辑的。然而，在某些情况下，Hibernate 无法很好地处理“适当”模型：具有许多关系的实体、一直使用的“热门”实体等。在这些情况下，如果Hibernate 的机制无济于事（例如二级缓存），您确实必须求助于此类“技巧”并自己完成一些工作。

Answer 3

我想我只会在表具有很多相同结构（“代码”、“描述”等）的情况下使用 Hibernate 的 @MappedSuperclass，这样我就可以减少代码行数。但除此之外，O/R 似乎是一条出路。

Answer 4

我遇到这个问题是因为我想知道人们在遇到需要查找其他实体的实体时会做什么。这样做的主要问题是，即使在测试中，您也不能再仅仅创建实例。我的首选方法是转向工厂或外部（例如非静态类）构建器。

总体而言，我遇到的问题是它非常基础，并且涉及很多容易出错的样板文件。例如，假设我有一个名为“列表”的内容，我必须跟踪它的来源（我在哪里找到它）。源是一个非常简单的实体，但现在我在列表中引用了它，如果不查找源然后注入适当的源，我就无法再创建列表。

如果可能的话，通过简单的注释来处理这个问题是有意义的，例如诸如mappedBy之类的东西，但引用id或name，然后容器可以进行查找和注入。

不过，我们很快就会看到这一点。