データベースデザイン：複数の潜在的な識別子

Question

FundsまたはAssetsテーブルを作成するときに、同じ問題が発生することがよくあります。すべてがAssetsの識別子と同じではありません。

例：70％がISINで、一部にはブルームバーグコードがあり、一部には両方があり、一部はローカルアカウンティングパッケージから来るもののみなどがあります。

一般私は一度開発者がに代替キーを移動したようなデータベースを継承

そのテーブルサロゲートPK、プラスすべての可能な識別子の異なるフィールド（Bloomberg, ISIN, AccoutingID、..）を与えることによって終わります子テーブル[Identifiers]は、可能なすべての代替キーを事前に知らなかったという事実に基づいています。

この識別子テーブルはこのように見えた：

• AssetID（サロゲート1）
• IdentifierType（例えば：ISIN）
• IdValue

最善の解決策は何ですか？

私はいくつかのNullを持つリスクがあっても、ISINはISINであり、Fundのよく定義された属性であるため、最初の（単一テーブル）が最適だと思います。

Answer 1

IDテーブルのメソッドがidValueのデータ型について仮定しているので、私は単一のテーブルを作成します。あなたはintではなくguidを使う新しい何かを得たらどうでしょうか？

アセットIDごとに別々の列を作成し、アセットに関するデータを別のテーブルに保存して、サロゲートIDをオフにすることもできます。あなたが取るアプローチは、主にデータの使用方法と、新しいアセットIDタイプを追加する頻度に依存します。

Answer 2

あなたのニーズに少し依存しますが、データベーススキーマの変更を必要としない新しい「識別子」レコードを挿入するための賢明なインタフェースを提供できるので、2番目のアプローチはしばしば柔軟性があります。

これは通常、存在する可能性のある識別子の数がわからない場合や、時間の経過とともに追加する必要があることがわかっている場合に使用されます。

前者の方法はクエリの記述が簡単で、識別子が静的な場合はおそらく最も簡単です。