postgresql - DDD : modelling aggregate entities' unique global/local id in PostgreSQL

Question

我读过埃里克·埃文斯 (Eric Evans) 的领域驱动设计一书，并且一直在尝试应用其中的一些概念。

在他的书中，Eric 谈到聚合以及聚合根应该如何具有唯一的全局 ID 而聚合成员应该如何具有唯一的本地 ID。我一直在尝试将该概念应用于我的数据库表，但遇到了一些问题。

我的 PostgreSQL 数据库中有两个表:设施和员工，其中可以将员工分配到单个设施。

过去，我会将 employees 表布局如下:

CREATE TABLE "employees" (
  "employeeid"  serial NOT NULL PRIMARY KEY,
  "facilityid"  integer NOT NULL,
  ...
  FOREIGN KEY ("facilityid") REFERENCES "facilities" ("facilityid")
);

其中 employeeid 是全局唯一的 ID。然后我会在后端添加代码以进行访问控制验证，防止一个设施的用户访问与其他设施相关的行。我觉得这可能不是最安全的方法。

我现在考虑的是这种布局:

CREATE TABLE "employees" (
  "employeeid"  integer NOT NULL,
  "facilityid"  integer NOT NULL,
  ...
  PRIMARY KEY ("employeeid", "facilityid"),
  FOREIGN KEY ("facilityid") REFERENCES "facilities" ("facilityid")
);

其中 employeeid 对于给定的 facilityid 是唯一的(本地)，但需要与 facilityid 配对才能在全局范围内唯一。

具体来说，这就是我要找的:

员工A (employeeid: 1, facilityid: 1)
员工B (employeeid: 2, facilityid: 1)
员工C(employeeid:1，facilityid:2)

其中 A、B 和 C 是 3 名不同的员工，并且...
将员工 D 添加到设施 1 会给他 key (employeeid : 3, facilityid: 1)
将员工 E 添加到设施 2 会给他 key (employeeid : 2, facilityid: 2)

我看到了两种实现此目的的方法:

1. 我可以使用触发器或存储过程来自动生成新的员工 ID 并将每个设施的最后一个 ID 存储在另一个表中以便更快地访问，但我担心并发问题并最终导致来自同一设施的 2 名员工使用相同的 ID。

2. 我可能会为每个设施创建一个新序列来管理 employeeid，但我担心最终会有数千个序列需要管理，并且在设施被删除的情况下需要删除这些序列。这有什么问题吗？这对我来说似乎很重。

我应该采用哪种方法？有什么我遗漏的吗？

Answer 1

我从你的问题中推断，你将为所有设施运行一个单一的数据库，或者至少如果你有一个本地数据库作为每个设施的“主”，那么数据将需要合并到一个中央数据库中没有冲突的数据库。

我会让 facilityid 成为主键的高阶部分。您可以使用简单的 SELECT max(employeeid) + 1 ... WHERE facilityid = n 方法分配新员工编号，因为将员工添加到任何一个设施大概不会每次发生数百次第二个来自多个并发源。这有可能导致偶尔的序列化失败，但我认为任何数据库访问都应该通过识别这些并自动重试事务的框架。