21
テーブルの主キーのベストプラクティスは何ですか？
テーブルを設計するとき、一意であり、主キーにする1つの列を持つ習慣を身につけました。これは、要件に応じて3つの方法で実現されます。 自動インクリメントするID列。 一意の識別子（GUID） 行ID列として機能できる短い文字（x）または整数（またはその他の比較的小さな数値型）列 数値3は、かなり小さなルックアップに使用されます。主に、一意の静的な長さの文字列コード、または年やその他の数値などの数値を持つテーブルを読み取ります。 ほとんどの場合、他のすべてのテーブルには、自動インクリメント整数または一意の識別子の主キーがあります。 質問 ：-） 私は最近、一貫した行識別子がなく、主キーが現在さまざまな列にわたってクラスター化されているデータベースでの作業を開始しました。いくつかの例： 日時/文字 日時/整数 datetime / varchar char / nvarchar / nvarchar これに有効なケースはありますか？私は常にこれらのケースのためにアイデンティティまたは一意の識別子の列を定義していたでしょう。 さらに、主キーがまったくない多くのテーブルがあります。これの正当な理由がある場合、それは何ですか？ テーブルが設計どおりに設計された理由を理解しようとしていますが、それは私にとって大きな混乱のように見えますが、それには十分な理由があったのかもしれません。 答えを解読するのに役立つ3番目の質問：複合主キーを構成するために複数の列が使用されている場合、代理キー/人工キーと比較して、この方法には特定の利点がありますか？主にパフォーマンス、メンテナンス、管理などについて考えていますか？