如何处理需要直接查询的复合主键实体表？

[EmyiaEllen]

最近接手一个项目，打算使用 Jimmer 简化和统一一下ORM层的代码，不过在编写Entity过程中出现了一个问题，项目数据库中含有符合主键表，这里先给出一个我自己之前使用Jimmer时遇到过的例子，然后再说另一个情况

-- ----------------------------
-- Table structure for sys_directory
-- ----------------------------
CREATE TABLE `sys_directory`  (
  `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `parent_id` bigint NOT NULL DEFAULT -1 COMMENT '父目录ID',
  `user_id` bigint NOT NULL DEFAULT -1 COMMENT '创建用户ID',
  `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '目录名称',
  `path` varchar(10000) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '目录路径（冗余字段）',
  `create_time` datetime NULL DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `sys_directory_unidx_user_id`(`user_id` ASC) USING BTREE COMMENT '用户ID索引',
  INDEX `sys_directory_unidx_parent_id`(`parent_id` ASC) USING BTREE COMMENT '父目录ID索引'
)

-- ----------------------------
-- Table structure for sys_directory_file
-- ----------------------------
CREATE TABLE `sys_directory_file`  (
  `file_id` bigint NOT NULL COMMENT '文件ID',
  `directory_id` bigint NOT NULL COMMENT '目录ID',
  `file_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '文件名称',
  `file_type` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL COMMENT '文件类型（后缀）',
  `update_time` datetime NOT NULL COMMENT '文件修改时间',
  PRIMARY KEY (`file_id`, `directory_id`, `file_name`) USING BTREE,
  UNIQUE INDEX `union_unidx_sys_user_file`(`file_id` ASC, `directory_id` ASC, `file_name` ASC) USING BTREE COMMENT '联合唯一索引'
)

-- ----------------------------
-- Table structure for sys_file
-- ----------------------------
CREATE TABLE `sys_file`  (
  `id` bigint NOT NULL COMMENT 'ID',
  `mask_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '文件掩名',
  `sha256` char(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT 'SHA-256',
  `size` bigint NOT NULL COMMENT '文件大小（字节）',
  `magic_type` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '文件真实类型',
  `count` bigint UNSIGNED NOT NULL COMMENT '文件引用计数',
  `expired_duration` bigint UNSIGNED NOT NULL COMMENT '文件过期延长存储时间',
  `upload_time` datetime NOT NULL COMMENT '创建时间',
  `change_time` datetime NOT NULL COMMENT '引用计数更新时间',
  `is_deleted` tinyint(1) NOT NULL DEFAULT 0 COMMENT '是否删除',
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `idx_sha256_sys_file`(`sha256` ASC) USING BTREE
)

这是一个小型的云文件存储数据库，文件上传后只在服务器留下唯一的数据，因此文件表中只有文件本身的数据和引用计数。这条记录是以 sha256 作为唯一标识的，意味着只要该值相同就视为同一文件（当然可能有冲突，这种情况就不讨论了）。

目录表则是对标用户的，每个用户都有自己的目录结构，所有用户都会创建一个自己的根目录，该根目录的父目录指向-1

当文件上传时，服务器会先插入记录，随后上传文件，待文件上传后，将文件的引用计数设为1。如果根据sha256查询出记录，即为重复上传，直接将文件引用计数+1，随后向 目录文件表 中插入用户存储文件的记录

sys_directory_file 表代表着用户的目录和文件关系，由于目录本身是划分用户的，所以该表没有用户ID。该表的三个主键表示在同一目录下，同一名称的同一文件只能存在一个。

目前对于 SysDirectoryFile 的定义只停留在了这里了

@Entity
@Table(name = "sys_directory_file")
public interface SysDirectoryFile {
    @OneToOne
    @JoinColumn(name = "file_id")
    @Nullable
    SysFile file();

    @OneToOne
    @JoinColumn(name = "directory_id")
    @Nullable
    SysDirectory directory();

    @Id
    @Column(name = "file_name")
    String fileName();

    @Nullable
    @Column(name = "file_type")
    String fileType();

    @Column(name = "update_time")
    LocalDateTime updateTime();
}

再往下就无法知道怎么做了，唯一的办法只能是修改数据库。

---

关于另一个项目，它的表比较简单，主要有五个字段：

key, type, cluster_id, created_time, modified_time

其中 key 是 namespace, collection, group 三种范围的任意一个ID，可以是命名空间ID，集合ID，组ID。type对应的是类型，cluster_id表示指向的集群。这个表的key和type就没有上述明确的指向了，但是还会涉及到直接操作。

这张表如果要适应jimmer也是很简单，修改表结构新加一列ID，然而这是不可能的

---

所以有什么办法能够处理这种联合主键的情况吗？ @babyfish-ct

[babyfish-ct]

https://babyfish-ct.gitee.io/jimmer-doc/docs/mapping/advanced/embedded

[EmyiaEllen]

那么对于第一种情况，复合主键或单独的主键本身是不能作为逻辑上的外键来设计吗？如果一张表被拆成两部分的情况下（将部分字段移出来和主键单独形成一张表）该怎么做呢？