私のアプリケーションでは、スーパーバイザーを持つケースを作成していますが、スーパーバイザは従業員または外部スーパーバイザのいずれかになる可能性があります。内部参照の従業員ID、または外部監督者名の名前の文字列です。外部キーまたは文字列を使用する場合のデータベース設計
どうすれば実装できますか？テーブル "case"を持ち、サブテーブル "case_internal_sv"と "case_external_sv"は行きますか？
あなたの質問に回答の根拠となる情報はたくさんありません。
すべてのタイプのスーパーバイザで共通のデータと機能がある場合は、その共通データを保持するテーブルが1つ必要になることがあります。そのテーブルはスーパーバイザのプライマリキー値を確立し、ケーステーブルはこのテーブルに外部キーを持ちます。内部または外部のスーパーバイザに固有の情報は別々のテーブルに格納され、これらのテーブルには共通のスーパーバイザーレベルのデータに戻ってくる外部キーもあります。
この設計は優れています。なぜなら、すべてのスーパーバイザのリストを検索するための場所が1つしかなく、コードや追加の制約なしに直接スーパーバイザ/ケースの関係をデータベースに適用できるからです。 2つの列の「1つだけ」が入力されます。
データベースの観点からは、内部と外部のスーパーバイザのデータが完全に分離されていても（おそらくそうではない場合でも）、この設計を使用することを検討することは十分に優れています。
これはまさに私が探していたものです、ありがとう！ – TheCokeGuy
データベースで複数の主キーを定義できる場合は、フィールドemployeeとフィールドemployee_typeを組み合わせて一意の主キーを構成できます。そうでない場合は、テーブル用に自動生成された主キーを持ち、従業員タイプのフィールドとemployee_idのフィールドを持つことができます。
どのデータベースをお使いですか？
私はPostgreSQLを使用しています – TheCokeGuy
テーブルが正規化されていると、ヘルプよりも害が大きくなります。要件に基づいてサブテーブルを持つ利点/欠点を評価する必要があります。
簡単な解決策は、テーブルに'sv_type'の列を持つことができます。 2列
'internal_sv_id'、従業員表'external_sv_name'、外部名を保存するためのNULL可能列にNULL可能外部キーを持っています。は、このデザインは完全に第三正規形に適合しない場合がありますが、それは高価な多くの加入を保存し、従業員表との整合性を許可することができます'sv_type'
に基づいてこれら二つの列のいずれかで監督をチェック。
私にとっては、疑いがある場合には、最も簡単な解決策に進んでいます。
これは私の考えです。 2つのフィールドを記述し、それらをヌル可能にすることを考えていました。そして、おそらく、どちらかを満たすように制約を作成するかもしれません。 – TheCokeGuy
このデザインは単純ではなく、完全性を保証するのが非常に難しくなります。プライマリキーと外部キーで単純に行うことはできず、2つの列の値を制約する追加のコードが必要になります。関与するJOINは、特にユーザーインターフェイスを構築し、潜在的に複数のクライアント間で整合性を強化するための追加コストが考慮される場合、世界中に多くの監督者がいないことを考慮すると、コストがかかることはまずありません。 –
外部スーパーバイザおよび内部スーパーバイザは、スーパーバイザの専用サブクラスですか？ –