2

獨特的全球/本地ID我已閱讀Eric Evans的領域驅動設計的書,我一直在嘗試應用一些概念。DDD:造型骨料實體的PostgreSQL中

在他的書中,埃裏克談到總量和總如何根應該有一個全局唯一的id,而總成員應該有一個唯一的本地ID。我一直在試圖將這個概念應用到我的數據庫表中,並且遇到了一些問題。

我在我的PostgreSQL數據庫的兩個表:設施,以及員工可以分配到一個單一的工廠員工。


在過去,我會如下鋪陳員工表:

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

其中僱員是一個獨一無二的ID。然後,我會在後端添加代碼以進行訪問控制驗證,從而防止一個設施的用戶訪問與其他設施有關的行。我有一種感覺,這可能不是最安全的做法。



我現在所考慮的是這個佈局:

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

其中僱員是唯一的(本地)對於一個給定facilityid,但需要與facilityid配對是唯一的全球性。

具體而言,這是我在尋找:

員工A(僱員:1,facilityid:1)
僱員B(僱員:2,facilityid:1)
僱員C(僱員:1, facilityid:2)

其中A,B和C是3名不同的員工和...
添加僱員d到設備1能給他鍵(僱員:3,facilityid:1)
加入僱員E到設施2將給他鑰匙(employeeid:2,facilityid:2)


我看到實現這一目標的方式有兩種:

  1. 我可以使用觸發器或存儲過程自動生成新的employeeids並存儲在另一個表中的每個設施的最後IDS以便更快地訪問,但我關注併發問題並最終得到來自同一個設施的2名具有相同ID的員工。

  2. 我可能會爲每個設施創建一個新的序列來管理employeeids,但我擔心最後會有數千個序列來管理,並且程序會刪除這些序列以防刪除設施。這有什麼不對嗎?這對我來說很重要。

我應該採取哪種方法?有什麼我錯過了嗎?

+1

我對你想要達到什麼(以及與DDD有什麼關係)有點困惑。您首先將一對多關係描述爲需求,然後在「這是我正在尋找的:」中顯示多對多關係的數據。你打算在這個有界上下文中暴露Employee實體嗎?通常,根據我的經驗,全局ID和本地ID之間的區別僅僅是使全局成爲UUID(或GUID)。然後你知道這個id在各種有界環境中是唯一的。 – 2012-04-07 08:22:04

+0

我編輯了我的問題,希望能夠讓它不那麼含糊。我想要的關係是一對多關係,Employee實體不會暴露在有界關係之外。 我主要是尋找最佳的方式來生成這些employeeids。 – akp 2012-04-07 08:51:10

回答

1

我從你的問題,你將所有的設備上運行一個單一的數據庫推斷,或至少,如果你有一個本地數據庫爲「主」爲每個設備數據將需要在組合中央數據庫無衝突。

我會使facilityid 高階主鍵的一部分。您可以使用簡單的SELECT max(employeeid) + 1 ... WHERE facilityid = n方法分配新員工編號,因爲將員工添加到任何一個工廠大概不會每秒從多個併發源中發生數百次。這可能會導致偶然的序列化失敗,但我認爲任何數據庫訪問都應該通過一個框架來識別這些數據庫並自動重試交易。

1

我想你在這裏誇大了總根概念。根據我對員工建模的理解(這取決於您的上下文),員工幾乎總是可能由另一個聚合根設施引用的引用

員工和設施幾乎都有自然鑰匙。對於員工來說,這通常是一些員工ID(打印在員工身份證上,或者至少保存在人力資源軟件系統中),並且設施具有這種自然密鑰也幾乎總是包含一些位置部分和一些數字,如「MUC-1 「位於慕尼黑的設施1。但這一切都取決於你的背景。如果員工和設施擁有這些自然鍵,那麼您的數據庫模型應該非常清晰。