私は、いくつかの DB データを正規化する任務を負っています。99% は問題ありませんが、問題が発生しました。
それは私の問題領域ではありませんが、類似の領域は本の領域です。書籍の詳細と、ベンダーの Web サイトでの書籍の表示方法を記録する必要があると想像してください (おそらく価格比較エンジン用)。
ベンダー A、B、および C では、各書籍が 1 つの数値識別子 (ベンダーごとに異なります) で表されますが、ベンダー D では、毎年リリースが 1 から始まるため、出版年も必要です。
A、B、および C のみを処理する必要がある場合は、書籍のマスター テーブルと、マスター書籍 ID をベンダー固有の ID にマッピングするルックアップ テーブルが必要です。しかし、ベンダー D はこれを破ります。たとえば、vendorID,vendorCode を一意のキーにすることはできません。これは、D の場合、vendorcode を再利用できるためです (コード 1 は毎年異なるエントリを持つことになります....)。
1 つの答えは、D のベンダー コードを結合変数にすることです。そのため、ID 123、年 = 2013 の場合は「123,2013」となり、ルックアップ コードでは次のようになります。
if(vendor = D){
...split the code in two and format the search request accordingly...
}
しかし、それは少し...ハッキーなようです。
DB正規化の微妙なトリックが欠けていますか? それとも、現実世界が必ずしもうまく正常化するとは限らないことを受け入れる必要がありますか?