2

私はEricEvansのドメイン駆動設計の本を読み、いくつかの概念を適用しようとしています。

エリックは彼の著書で、アグリゲートと、アグリゲートルートが一意のグローバルIDを持つべきであるのに対し、アグリゲートメンバーは一意のローカルIDを持つべきである方法について説明しています。私はその概念をデータベーステーブルに適用しようとしてきましたが、いくつかの問題が発生しています。

PostgreSQLデータベースには2つのテーブルがあります。1つのファシリティに従業員を割り当てることができるファシリティと従業員です。


以前は、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（従業員ID：1、施設ID：1）
従業員B（従業員ID：2、施設ID：1）
従業員C（従業員ID：1、施設ID：2）

ここで、A、B、Cは3人の異なる従業員であり、...
施設1に従業員Dを追加すると、キーが与えられます（employeeid：3、facilityid：1）。
施設2に従業員Eを追加すると、キーが与えられます（employeeid： 2、facilityid：2）


これを達成する方法は2つあります。

  1. トリガーまたはストアドプロシージャを使用して、新しい従業員IDを自動的に生成し、すべての施設の最後のIDを別のテーブルに保存して、すばやくアクセスできるようにすることもできますが、同時実行の問題が懸念され、同じ施設の2人の従業員が同じIDを使用することになります。

  2. 従業員IDを管理するために施設ごとに新しいシーケンスを作成することもできますが、管理するシーケンスが数千になり、施設が削除された場合にそれらのシーケンスを削除する手順が必要になるのではないかと心配しています。これに何か問題がありますか？重そうです。

どのアプローチを取るべきですか？私が見逃しているものはありますか？

4

2 に答える 2

1

あなたの質問から、すべての施設に対して単一のデータベースを実行するか、少なくとも各施設の「マスター」としてローカルデータベースを使用している場合、データを中央データベースで衝突なしに組み合わせる必要があると推測しています.

ファシリティ ID を主キーの上位部分にします。おそらく単純なアプローチを使用して新しい従業員番号を割り当てることができます。これSELECT max(employeeid) + 1 ... WHERE facilityid = nは、1 つの施設に従業員を追加することは、複数の同時ソースから 1 秒間に何百回も発生することではないからです。これにより、時折シリアライゼーションの失敗が発生する可能性がありますが、データベースへのアクセスは、それらを認識してトランザクションを自動的に再試行するフレームワークを介して行う必要があるというのが私の意見です。

于 2012-04-07T15:08:35.093 に答える
1

ここで集約ルートの概念を強調しすぎたと思います。従業員のモデル化に関する私の理解では (コンテキストによって異なります)、従業員はほとんどの場合、別の集約ルート機能によって参照される集約ルートです。

従業員と施設の両方に、ほぼ常に自然キーがあります。従業員の場合、これは通常、従業員 ID (従業員 ID バッジに印刷されているか、少なくとも人事ソフトウェア システムで維持されています) であり、施設にはこの自然キーもあり、ほとんどの場合、場所の一部と「MUC-1」のような番号が含まれています。ミュンヘンにある施設1。しかし、それはすべてあなたの文脈に依存します。従業員と施設がこの自然キーを持っている場合、データベース モデルは非常に明確になります。

于 2012-04-08T07:50:44.810 に答える