これはデータベースを設計する標準的な方法ですか？

最近、職場でデータベースでリレーションシップがどのように定義されるかを知り、これが標準的な方法であるかどうか疑問に思いました。

プロセスAとプロセスBの2つのプロセスがあるとします。プロセスBはプロセスAの結果に依存するため、プロセスBの実行とプロセスAの実行の間に定義する必要がある関係があります。これが関係の定義方法です。

TableProcessA:
Id

そして

TableProcessB:
Id
ProcessAId

さて、これまでのところ、私には物事は理にかなっていますが、それから、私とテーブルのデザインに対する私の理解が少し奇妙になっています。TableProcessAまたはTableProcessBで行が作成されるたびに、それぞれに対してグローバルに一意のIDを作成する関数が呼び出されます。そのため、基本的に、Idはテーブルだけでなくデータベース全体に対しても一意であるため、TableProcessAおよびTableProcessBのすべてのIdフィールドには一致が含まれません。

私の質問は、これはどのくらい標準的ですか？各テーブルには、データベース全体ではなく、テーブルに固有の自動インクリメントIDが必要であるという考えに思いつきました。

これは奇妙な習慣ではありません。これらはGUIDまたはグローバルに一意のIDと呼ばれます。これは、GUIDが指定されていると、IDがどのデータに属しているかが正確にわかるため、どこでも一意になるためです。GUIDは、類似したデータの異なるソースをマージする場合に最適です。たとえば、さまざまな店舗の在庫。

私はいくつかの調査を行い、これがなぜあなたの環境で一般的な習慣であるのかを見つけます。必要な場合もあれば、必要ない場合もあります。

原則として、データベース全体で一意のIDを持つことは悪くありませんが、私の経験ではかなり珍しいです。グローバルに一意のIdキーを維持するための特定の要件がない限り、エンティティタイプまたはオブジェクトはタイプ固有である傾向があり、通常は不適切な結合が発生しないため、通常のIDの使用は問題ありません。

余談ですが、GUIDを主キーまたは代理キーとして使用しないことを強くお勧めします。これは、intの4倍のスペースを占めるためです。マルチギガバイトのディスクの時代には、それは重要ではないと言っているかもしれませんが、数百万行のデータがある場合でも、ディスクからの読み取りやネットワーク経由の転送にはリソースが必要です。私はサブジェクトインデックスを使用していますが、GUIDはランダムな性質があるため主キーでは不適切であり、通常は大幅な断片化を引き起こします。

現在、このデータベースには遅すぎる可能性がありますが、将来のためにそれを覚えておいてください

プロセスは、プロセスインスタンスへの参照としてGUIDを含むレコードを作成できますが、GUIDをキーとして使用することは必ずしも最適ではありません。

データベースキーとしてGUIDを使用することには3つの主要な欠点があると思います。GUIDを使用する説得力のある理由がない限り、GUIDを回避します。データがどのテーブルから取得されたかはすでにわかっているため、グローバルに一意のプロパティは、テーブル内でローカルに一意であるキーを使用するよりも優れていることに注意してください。

不便：データベースのアドホッククエリを実行する場合、GUIDを入力するのは非常に簡単ではありません。次に例を示します。

select *
  from Foo
 where FooID = 12345

対

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

後者は、カットアンドペーストするためのGUIDのソースが必要であることを意味します。

2.自然順序：自動インクリメントの主キーには、トランザクションがシステムに入力された順序でトランザクションを自然に順序付ける副作用があります。これは非常に便利です。GUIDは通常、順番に生成されないため、この点では役に立ちません。

3.サイズ：最近は問題は少なくなっていますが、GUIDは16バイトです。テーブルとそれを含むすべてのインデックスでより多くのスペースを使用します。

正常とは言えませんが、このように設定しても異常ではありません。