2

我正在努力为以下类别（如场景）选择正确的映射： 

The food entity has a composed primary key made of 3 fields plus a name field:
╔════════╦═══════╦════════╦════════════════╗
║ family ║ class ║ sector ║ name           ║ - family INT UNSIGNED NOT NULL
╠════════╬═══════╬════════╬════════════════╣ - class INT UNSIGNED DEFAULT NULL
║ 1      ║ NULL  ║ NULL   ║ Natural        ║ - sector INT UNSIGNED DEFAULT NULL
║ 1      ║ 2     ║ NULL   ║ Greens         ║ - name VARCHAR(200) NOT NULL
║ 1      ║ 2     ║ 1      ║ Spring veggies ║ - PRIMARY KEY (family, class, sector)
║ 1      ║ 2     ║ 2      ║ Spring fruits  ║
║ 1      ║ 2     ║ 3      ║ Summer veggies ║
╚════════╩═══════╩════════╩════════════════╝

这张表是关于食物类别的。它们只能是一个匹配family++的class条目sector。填充的主键字段越多，类别记录就越“具体”。具有family+ class+的记录sector（即实际的扇区类别）将具有 2 个隐式父项：a/ A类记录，具有相同family但class设置sector为 NULL，b/家庭记录，最高类别，具有相同的家庭值但两者都class设置sector为NULL。

一个部门记录将有 0 个孩子，但有 2 个父母意味着$spring_fruit_object->getParents()将返回一组食品实体，例如[natural_hydrated_object, greens_hydrated_object]（急切地）。

实际上，我担心根据上面列出的规则，现有的关联映射都不能自动处理这个用例。我可能必须从存储库类构建自定义查询。

您将如何处理这种情况？谢谢你。

4

1 回答 1

0

（关闭：这意味着每个家庭+班级+部门只允许一种食物。你确定那是你想要的吗？看起来很奇怪）

我应该添加一个自动递增的主键，将当前的主组合键转换为一个 UNIQ 索引，然后简单地使用带有查询构建器的存储库吗？

IMO，应避免使用复合主键。它们可能很诱人，因为它们很有意义，但是：

  • 慢点
  • 不得不与你的日常生活有所不同，让你工作更慢
  • 自动增量 ID 几乎没有增加任何额外内容
  • 您将不得不为某些事情生成一个组合 ID，例如路由。

Doctrine 文档提到了 3 个用例（https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/tutorials/composite-primary-keys.html#use-case-1-dynamic-attributes），一切都是有效的，但我只会考虑案例 1，因为这增加了真正的价值——你不必创建属性，简化了 API。

于 2018-07-15T00:14:37.377 回答