テーブルに必要な外部キーが多すぎる場合、どのような選択肢がありますか？

パーツを定義し、パーツ番号、説明、価格、重量などの情報を保持するベーステーブルがあります。ベーステーブルを参照し、タイプ/カテゴリに基づいてパーツに関する追加情報を提供する約400のテーブルもあります。

最初は外部キー制約を使用して、400のパーツ固有のテーブルのいずれかで参照されている場合、そのパーツをベーステーブルから削除できないようにしましたが、SQL Server 2005の推奨される最大253の外部キーにすぐに達しました。

この状況で、データの整合性を保証する外部キーに代わるものはありますか？データにアクセスする際のパフォーマンスの問題は確認されていませんが、クエリプランが複雑すぎるため、ベーステーブルの既存の部分の更新は失敗します。

パーツをグループ化する方法がある場合は、回避策として中間テーブルを導入できる場合があります。 これは機能しません。

Parts
+ Table 1
+ Table 2
+ ...
+ Table 400

しかし、これらの線に沿った何かがかもしれません。

Parts
+ RedOrangeYellow parts
  + Table 1
  + Table 2
  + ...
  + Table 200

+ GreenBlueIndigoViolet parts
  + Table 201
  + Table 202
  + ...
  + Table 400

ただし、これを行うことをお勧めする前に、DDLをしっかりと確認したいと思います。そして、これを行う場合は、ID番号をあちこちに投げ始めないでください。「GreenBlueIndigoVioletパーツ」を含めずに、「Table 400」を「パーツ」に直接結合できる必要があります。

本当にテーブルを結合できない場合はTRIGGER、削除を防ぐためにベーステーブルにを作成してみませんか？

ここから開始：http : //msdn.microsoft.com/en-us/library/ms189799(v=sql.90).aspx

400以上のテーブルを1つに置き換えます。3つのフィールドのみが必要です（+1オートナンバーまたは必要に応じて任意の主キー。他のフィールドから作成する必要はありません）

アイテムID属性値

したがって、他のテーブルでは各フィールドが属性を表しますが、このテーブルでは、属性はすべて1つのフィールドにあります。あなたはこのようなものを持っているでしょう

ItemID属性値

靴下素材ウール

靴下の色赤

靴下重量20ポンド

エイリアンプラネットアルファケンタウリ

エイリアンカラーパープル

エイリアンフレンドリー

ItemIDは、おそらく数字/英数字です。次に、必要に応じて、必要に応じて列ヘッダーとしてAtrributes付きのクロス集計を作成します。これにより、「Alpha Centauriのすべてのアイテムを表示」などのクエリを実行できるようになります。これにより、エイリアンと、人類を一掃する疫病を含む隕石のフラグメントを返すことができます（これからです...）。

レコードの数によっては最適化が難しい場合がありますが、これを設計するにははるかに良い方法です。重複が少ないレシピの束（1万以上）を含むデータベースに対しても同じことを行いました。その場合はうまくいきました。本当に速度の問題はありませんでした。あなたが扱っている数によっては、あなたのほうが難しいかもしれません。