具有更多数据字段的数据库 Junction/association table
database Junction/association table with more data fields
我不喜欢在 junction/association table 中有两个以上的字段（例如：pk1 和 pk2）。但是，我确实遇到了一种情况，但不确定解决它的最佳方法是什么。
Table 1:
合同（编号、价格、描述）
Table 2:
人物（身份证、名字、姓氏）
Table 3 (junction/association)
person_contract (person_id, contract_id)
所以一个合同可以有一个或多个人，一个人可以有一个或多个合同。因此需要 junction/association table; person_contract.
到这里没有问题。现在每个合同的人都有一个序列来表示他们对给定合同的重要性。例如：
- person1, contract1, sequence = 1
- person2, contract1, sequence = 2
- person3, contract1, sequence = 3
- person1, contract2, sequence = 2
- person4, contract2, sequence = 1
问题是合同的人员序列保存在哪里？将序列添加到 junction/association table 对我来说不合适。如果可能的话，我正在寻找更好的方法。
在这种 table 中包含其他字段没有错。对于您所描述的特定场景，它实际上非常有用，因为您可以添加一个 Rank 列，然后如果您想找到最重要的人，可以使用它对与合同关联的人员进行排序。我之前使用过非常相似的模式并取得了成功。
从数据建模的角度考虑这一点，在实体关系术语中，这是一个关联实体。 Wikipedia 关于这件事有话要说：
- [关联实体]也是一个实体，因为它可能有自己的属性。
- [关联实体] 还可能包含...有关关系的其他信息。
因此，如果某些数据是关于由特定 table 建模的关系，那么它属于那个 table。
我经常发现用这种东西跳出数据库思维是有帮助的——而不是把它看作一个结 table，你可以把它看作是一群人一起签订合同.您所质疑的重要性数据在概念上描述了关于特定合同的那群人的一些事情。
至于你在评论中的注释，你开始认为这可能是有问题的，因为 Hibernate 如何基于 tables 生成实体，我已经看到 ORM 工具在两者中创建的一些非常有问题的东西方向（即糟糕的自动生成数据库和糟糕的自动生成代码）。质疑输出 - 正如你所做的那样 - 似乎是明智的。我不知道这些问题是否可以解决，或者是否是使用自动生成工具不可避免的成本；可能值得针对 Hibernate 专家提出一个新问题，即是否可以让它接受这种 table 并仍然自动生成像样的代码。
我不喜欢在 junction/association table 中有两个以上的字段（例如：pk1 和 pk2）。但是，我确实遇到了一种情况，但不确定解决它的最佳方法是什么。
Table 1: 合同（编号、价格、描述）
Table 2: 人物（身份证、名字、姓氏）
Table 3 (junction/association) person_contract (person_id, contract_id)
所以一个合同可以有一个或多个人，一个人可以有一个或多个合同。因此需要 junction/association table; person_contract.
到这里没有问题。现在每个合同的人都有一个序列来表示他们对给定合同的重要性。例如： - person1, contract1, sequence = 1 - person2, contract1, sequence = 2 - person3, contract1, sequence = 3 - person1, contract2, sequence = 2 - person4, contract2, sequence = 1
问题是合同的人员序列保存在哪里？将序列添加到 junction/association table 对我来说不合适。如果可能的话，我正在寻找更好的方法。
在这种 table 中包含其他字段没有错。对于您所描述的特定场景，它实际上非常有用，因为您可以添加一个 Rank 列，然后如果您想找到最重要的人，可以使用它对与合同关联的人员进行排序。我之前使用过非常相似的模式并取得了成功。
从数据建模的角度考虑这一点，在实体关系术语中，这是一个关联实体。 Wikipedia 关于这件事有话要说：
- [关联实体]也是一个实体，因为它可能有自己的属性。
- [关联实体] 还可能包含...有关关系的其他信息。
因此，如果某些数据是关于由特定 table 建模的关系，那么它属于那个 table。
我经常发现用这种东西跳出数据库思维是有帮助的——而不是把它看作一个结 table，你可以把它看作是一群人一起签订合同.您所质疑的重要性数据在概念上描述了关于特定合同的那群人的一些事情。
至于你在评论中的注释，你开始认为这可能是有问题的，因为 Hibernate 如何基于 tables 生成实体，我已经看到 ORM 工具在两者中创建的一些非常有问题的东西方向（即糟糕的自动生成数据库和糟糕的自动生成代码）。质疑输出 - 正如你所做的那样 - 似乎是明智的。我不知道这些问题是否可以解决，或者是否是使用自动生成工具不可避免的成本；可能值得针对 Hibernate 专家提出一个新问题，即是否可以让它接受这种 table 并仍然自动生成像样的代码。