タグ

設計とデータに関するburnercrewのブックマーク (2)

  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • クラスタ化インデックスの設計ガイドライン

    PRIMARY KEY 制約を作成すると、単一または複数の列に基づく一意のインデックスが自動的に作成されます。既定では、クラスタ化インデックスが作成されますが、制約を作成する際に非クラスタ化インデックスを作成するように指定することもできます。 範囲クエリで使用可能。 UNIQUE プロパティを指定せずにクラスタ化インデックスが作成された場合、データベース エンジンにより、4 バイトの uniqueifier 列が自動的にテーブルに追加されます。必要があれば、各キーを一意にするため、データベース エンジンにより自動的に uniqueifier 値が行に追加されます。この列とその値は、内部的に使用されるもので、ユーザーが参照したりアクセスすることはできません。 クエリに関する注意点 クラスタ化インデックスを作成する前に、データがどのようにアクセスされるかを理解しておいてください。次の処理を行う

    クラスタ化インデックスの設計ガイドライン
  • 1