サーバーおよびデータベース インベントリ用のデータベースを設計しようとしていますが、優れたデータベース設計を探しています。サーバー クラスター、スタンドアロン サーバー、およびデータベース用のテーブルがあります。データベースで次の関係を表現したいと思います。
クラスターからサーバーへの 1 対多の関係。
データベースからクラスター/サーバーへの 1 対多の関係。
難しいのは 2 番目の関係にあります。これは、クラスターとサーバーが別のテーブルにあり、クラスターがサーバーで構成されているためです。この関係を表す最良の方法は何ですか?
これは、状況の関係ビューにあるようです。
Cluster : name, other attributes of cluster
Server : name, optional FK to cluster, other attributes of a server
Database : name, (FK to cluster OR FK to server)
問題は、現実世界の状況がやや複雑であり、リレーショナル テクノロジがきれいに反映されていないことです。
Host -- an abstract superclass for places a database can run.
Cluster (extends Host) : name, etc.
Server (extends Host) : name, optional FK to cluster.
Database : FK to Host
この種の「サブエンティティ」の問題を処理するには、いくつかの選択肢があります。
ホスト、クラスター、サーバーを 1 つのテーブルにまとめます。これにより、ホスト (クラスターとして) とホスト (サーバーとして) の間に再帰的な関係が生まれます。これは面倒ですが、ホスト、クラスター、およびサーバー用に単一のテーブルを作成します。結果のテーブルには多くの null があります (クラスター行は列の 1 つの束を使用し、サーバー行は列の別のセットを使用します)。ホストのサブエンティティを区別するために列を追加する必要があります。
ホスト情報をクラスターとサーバーにプッシュします。これは、Host テーブルに多くの共通情報があり、Cluster または Server テーブルにサブクラス固有の情報がほとんどない場合に役立ちます。Cluster テーブルと Server テーブルは、いくつかの列が異なるだけで非常によく似ています (基本的には Host のクローン)。
ホストの識別子に基づいて、(ホストとクラスター) または (ホストとサーバー) 間の結合を使用します。かなり複雑ですが、すべてのデータベースがホストに結合され、ホストの完全なリストが、サーバーに結合するホストとクラスターに結合するホストの結合であるため、これは適切にスケーリングされます。
データベースでオプションの FK フィールドを使用します。これには、データベースの完全なリストを取得するために、クラスターに結合されたデータベースとサーバーに結合されたデータベースの間の和集合が必要です。2 つの FK フィールドの NULL 値のさまざまな組み合わせを区別できるように、各データベースには識別子が必要になる場合があります。4 つの組み合わせが考えられますが、そのうち 2 つが適切で、2 つが禁止されている可能性があります。単純に 2 つの null 許容 FK を使用しようとしても、通常はうまくいきません。そのため、クラスター上のデータベースとサーバー上のデータベースを、何にも割り当てられていないデータベースと、ホスティングが不明なデータベースと、その他のステータスから分離するためのステータス フラグが必要になることがよくあります。関連する。
オプション 1: データベース テーブルに 2 つのフィールドがあります。1 つはサーバーを指し、もう 1 つはクラスターを指します。それらの 1 つを null のままにします。
オプション 2: 別のアプローチは、各スタンドアロン サーバーのクラスターにもエントリを追加し、そのテーブルのみにリンクすることです。
オプション1は実際には最もクリーンなソリューションではありません（コメントに同意します）ので、オプション2に進みます:)