当前位置: 首页 > 面试题库 >

为什么在hibernate状态下不鼓励使用复合键?

苗阳文
2023-03-14
问题内容

这是来自Hibernate的官方教程:

还有一个替代<composite-id>声明,该声明允许使用组合键访问旧数据。强烈建议不要将其用于其他任何用途。

为什么不鼓励使用复合键?我正在考虑使用一个三列表,其中所有列都是外键,并且一起形成一个主键,这在我的模型中是有意义的关系。我不明白为什么这是一个坏主意,特别是我将在它们上使用索引。

有什么选择?创建一个额外的自动生成的列并将其用作主键?无论如何,我仍然需要查询我的3列!

简而言之,为什么这句话是正确的?还有什么更好的选择?


问题答案:

他们由于以下几个原因而劝阻他们:

  • 使用起来很麻烦。每次需要引用一个对象(或行)时,例如在Web应用程序中,例如,您都需要传递3个参数,而不仅仅是一个。
  • 他们效率低下。数据库不仅需要哈希整数,还需要哈希3列的组合。
  • 它们导致错误:开发人员不可避免地会错误地实现主键类的equals和hashCode方法。或者它们使它可变,并在将其值存储在HashSet或HashMap中后对其进行修改
  • 他们污染了架构。如果另一个表需要引用此3列表,则它将需要3列,而不只是3列作为外键。现在,假设您采用相同的设计,并且将此3列外键作为此新表的主键的一部分,您将很快拥有4列主键,然后在下一个表中具有5列PK,依此类推等等,导致数据重复和模式变脏。

替代方法是,除其他三列外,还具有单列自动生成的主键。如果要使三列的元组唯一,请使用唯一约束。



 类似资料:
  • 大多数在线来源都表明您可以静态链接glibc,但不鼓励这样做;例如centos包repo: glibc静态包包含用于静态链接的C库静态库。你不需要这些,除非你静态链接,这是非常不鼓励的。 这些消息来源很少(或从未)说明为什么这是个坏主意。

  • 问题内容: 这是来自Hibernate的官方教程: 还有一个替代声明,该声明允许使用组合键访问旧数据。强烈建议不要将其用于其他任何用途。 为什么不鼓励使用复合键?我正在考虑使用一个三列表,其中所有列都是外键,并且一起形成一个主键,这在我的模型中是有意义的关系。我不明白为什么这是一个坏主意,特别是我将在它们上使用索引。 有什么选择?创建一个额外的自动生成的列并将其用作主键?无论如何,我仍然需要查询我

  • Django Rest框架序列化程序不调用。给出的解释是,这导致了Django Rest Framework 3.0发行说明中的“更清晰的关注点分离”: 此更改还意味着我们不再使用方法,但在序列化程序上显式执行所有验证。这提供了更清晰的分离,并确保ModelSerializer类上没有自动验证行为,而这些行为也不能轻松地复制到常规序列化程序类上。 但是DjangoRest框架的作者试图分离哪些问题

  • 问题内容: 关于Java EE开发的第一件事是,我不应该在Java EE容器中生成自己的线程。但是当我考虑它时,我不知道原因。 您能清楚地解释为什么不鼓励这样做吗? 我确信大多数企业应用程序都需要某种异步作业,例如邮件守护程序,空闲会话,清理作业等。 因此,如果确实不应该产生线程,那么在需要时正确的方法是什么? 问题答案: 不建议这样做,因为环境中的所有资源都应由服务器进行管理,并可能由服务器进行

  • 问题内容: Model.clean验证模型序列化器时,Django Rest Framework序列化器不会调用。给出的解释是,这导致了Django Rest Framework 3.0发行说明中的 “更清晰的关注点分离” : ModelSerializer验证和ModelForm之间的差异。 此更改还意味着我们不再.full_clean()在模型实例上使用该方法,而是在序列化程序上显式执行所有验