0

複数のデータベーステーブル間で一意のIDフィールドを維持するための最良の方法は何ですか？

私のデータベースには企業と人の両方が含まれており、両方のエンティティに一意のIDフィールドが関連付けられている必要があります。さらに、IDを外部キーとして使用して、企業または個人のいずれかを参照できる他のテーブル（たとえば、住所）があります。

私が考えているいくつかのアイデアは次のとおりです。

  • 行が挿入されたときに計算される非自動番号IDフィールドを使用します。これで一意であるという私の問題は解決しますが、関連するプロパティ（住所など）で何かを検索したいときはいつでも、探しているレコードが含まれている両方のテーブルをチェックする必要があります。

  • オートナンバーIDにプレフィックスを追加して、IDを検索するテーブルを識別します。ただし、関連付けられたテーブルのIDフィールドは、おそらく文字列になるか、関連付けられているテーブルのフラグが含まれるため、どのようになるかわかりません。パフォーマンスに影響します。

  • PeopleandBusinessesを1つのテーブルにマージします。これに関する私の問題は、人と企業が異なるプロパティを持ち、別々のフィールドを必要とすることです。私は別々のエンティティに別々のテーブルを持っていることを好むので、この種は私の性質に反します。

  • 一意のIDフィールド、個人または企業のIDフィールド、およびどちらであるかを示すフラグを含むマスターテーブルを作成します。次に、そのIDを外部参照番号および関連するすべてのテーブルで使用します。

  • 私はdbaではないので、私が気付いていないこれを処理するいくつかのより良い方法

私が使用するソリューションが何であれ、多数のレコードを簡単に処理できる必要があり（これが置き換えるデータベースには数百万のレコードがあります）、MSSqlServer上にあります

4

8 に答える 8

6

その設定で外部キーを設定することはできません。1つの外部キーで、2つの異なるテーブルを参照することはできません。

私は次のいずれかを行います：

もちろん、2つのエンティティのそれぞれからアドレステーブルで2つの別々の列を使用することもできます。BusinessIdとpeopleid。FKはnullを持つことができるので、これは問題ありません。次に、FK関係を適用して、データの整合性の問題が発生しないようにすることができます。

または、ビジネスと人の両方を含むがフィールドが非常に少ない親テーブルを設定します（実際に共通しているフィールドのみ、場合によっては一意のIDとレコードタイプのみ）。ビジネス、人、住所などの子テーブルを作成できます。

または、個々の子テーブルを設定します。ビジネス、次にビジネスアドレス、人と人のアドレスなどです。次に、2つの論理エンティティ間でIDを一意に保つ必要はありません。

1つの可能性を忘れました。多対多の関係がある場合は、Address、Business、People、そしていくつかのリンクテーブル、BusinessAddress、PeopleAddressを使用できます。GUIDはパフォーマンスに悪影響を与える可能性があるため、別の選択肢がある場合は、個人的にGUIDを使用しません。

于 2010-06-18T19:14:59.033 に答える
2

考えを逆にすることもできます。

住所に個人または会社のIDを設定する代わりに、個人または会社に住所IDを設定します。

これは私の本の中でそれについて考えるより自然な方法です...人は住所を持っています。

于 2010-06-18T19:15:00.643 に答える
1

これがGUIDの目的です。

于 2010-06-18T19:07:18.057 に答える
1

これを行うにはいくつかの異なるパターンがありますが、最も簡単で最も柔軟なのは、一意の識別子（GUID）を使用することです。ほとんどのDBには、これらを構築するための機能があります（たとえば、SQL ServerはNEWID（）です）。それらは他のIDフォームよりも大きいですが、あなたが探している仕事をします。

于 2010-06-18T19:08:03.483 に答える
1

一部のデータベースでは、null値を持つ外部キーを使用できます。一部はそうではなく、SQLServerがそうするかどうか思い出せません。許可されている場合は、アドレステーブルに2つのID列を含めることができます。1つはPeopleを指し、もう1つはBusinessを指します。そのアプローチには長所と短所もあります。短所の1つは、おそらくDBAに嫌われているということですが、データベースで許可されている場合は、おそらくそれが代替手段の1つである可能性があります。

于 2010-06-18T19:14:27.550 に答える
1

ビジネスと人の両方を識別する「スーパータイプ」テーブルを作成し、そのテーブルを外部キーで参照します。これは、この状況の一般的なパターンです。参照：パーティデータモデル。

于 2010-06-19T06:48:56.597 に答える
0

GUIDは、一意の識別子としては他に何もありません。
GUIDの問題は、特にDBが巨大になる場合は、GUIDのサイズです。
結合（インデックス、外部キーなど）では使用しないでください。
この正確なDB設計では、レコード数が多くなりすぎたときに整数に戻す必要がありました。
また、個人/企業/住所のデザインには注意が必要であることも指摘しておきます。それは多対多の関係です。ビジネス/個人は複数のアドレスを持つことができ、アドレスは複数のビジネス/個人用にすることができます...

ビジネスと個人を分離したい場合は、関係を保持するために2つのテーブルPersonAddressとBusinessAddressを使用でき、両方のアドレスを検索するときに結合を行う必要があります。または、両方のビジネスの1つのテーブルEntityAddressを使用できます。 EntityNatureフィールドと一緒に、それがビジネスであるか個人であるかを示す人。

于 2010-06-18T19:21:31.387 に答える
0

ビジネスマンと人々は本当に、完全に、ビジネスから分離していますか？

「彼らが生まれた日」でさえ、彼らにはこれまでに共通するものは何もありませんか？

ビジネスはそれらの両方を「カウンターパーティ」として扱いませんか？

私が説明しようとしているのは、平均的なIT（いわゆる）「プロフェッショナル」が通常見ている通常の目がくらむような眼鏡なしで、ビジネスを十分に見つめていることです。そうすれば、探している共通点を非常に迅速に見つけることができます。にとって。

これらの共通点を記録するためにデータベースにテーブルを定義し（それが識別にすぎない場合でも）、アドレスがそのテーブルを参照するようにします。

于 2010-06-20T23:34:14.853 に答える