1

私のデータベースには 2 つのテーブルがあり、1 つは都市の距離マトリックスで、もう 1 つは都市を保持しています。私の最初の構造は次のようなものでした：

  • 街
    • ウイド
    • 名前
    • 緯度
    • 経度

と

  • 距離
    • FromCityID
    • 都市IDへ
    • 距離長さ

UUIDは CITY テーブルの主キーであり、FromCityIDCITYToCityIDをそれぞれ外部キーとして参照します。2 つの都市間の距離は一意である必要があるため、どちらも DISTANCE テーブルの複合主キーです。

UUIDしかし、都市と距離を保持する XML からこのデータベースにデータをアップロードするため、自動インクリメントを主キーとして使用したくないことに気付きました。また、距離には、現在の XML で言及されている都市だけでなく、データベースから以前に保存された都市も含まれる場合があります。

データベースと XML で同じ ID のシステムが必要です。緯度/経度が最適なオプションと思われるため、テーブルを次のように変更しました。

  • 街
    • 名前
    • 緯度
    • 経度

と

  • 距離
    • FromCityID緯度
    • FromCityID経度
    • ToCityID緯度
    • ToCityID経度
    • 距離長さ

LatitudeCITY テーブルのLongitude複合主キーです。FromCityIDLatitude/FromCityIDLongitudeおよびToCityIDLatitude/ToCityIDLongitudeはそれぞれ CITY を外部キーとして参照し、4 つの列はすべて DISTANCE テーブルの複合主キーです。

しかし、主キーとして 4 つの列を使用するのは悪い設計です。この場合、何が一番いいですか？

4

3 に答える 3

3

私はこの声明に同意しません：

ただし、4列を主キーとして使用するのは不適切な設計です。

悪い設計とは、必要なことを実行しない設計、またはデータベースの不整合を許容する設計です。あなたの場合、1つの仮定をしている限り、4列の主キーに問題はありません。つまり、このテーブルへのメインアクセスルートは、主キーのすべての列を使用します。この場合は問題ありません。テーブル全体を一意のインデックスに入れ、キーの4つの列に個別の一意の制約を設定します。

4列のインデックスの問題は、4番目のリーフでテーブルにアクセスしようとしたときです。おそらく、インデックスをまったく使用しないでしょう。その後、4番目のリーフで定期的にインデックス検索を行う必要が生じた場合は、別のインデックスを追加する必要があります。途方もなく過剰にインデックス付けされたテーブルになってしまう可能性があります。

それを回避する方法は、負荷をずらすことです。XMLデータをメインデータベーステーブルに直接ロードしないでください。それらをセカンダリテーブルにロードし、プロセスを実行して、この都市がすでに存在するかどうかを確認します。含まれている場合は、追加しないでください。そうでない場合は、新しい代理キーを生成し、CROSS JOINを実行して、すべての新しいレコードをDISTANCEに追加します。

于 2012-11-03T11:12:11.563 に答える
1

テーブルの「物理的」設計を忘れないでください。距離行列については、インデックス構成テーブル (IOT) の使用を検討し、列を圧縮します。

ここで、AskTom での同様の質問 (距離テーブルに関する) の議論を参照してください。

http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:239614547000#52902724002052

于 2012-11-03T11:26:09.740 に答える