7

Partner Idorなどのビジネスエンティティ識別子として自動インクリメント主キーを使用するのは悪い考えですか、それとも良い考えAccount Numberですか?

また、そのアプローチを選択した場合、どのような落とし穴に直面する可能性がありますか?

4

2 に答える 2

6

全員が同じ意見だとは思いませんが、悪い習慣だと思います。ID を「キー」としてユーザーに渡すことは、いくつかの理由から、私の意見では良くありません。

  • ID はユーザーにとって自然なものではありません。彼らはプロジェクト「1474623」について話しているのではなく、プロジェクト「ABC」について話しているのです。彼らは「363528」という人物について話しているのではなく、「パトリック・ホフマン」について話しているのです。
  • IDは壊れやすいです。それらが変わらないことに本当に頼ることはできません。別のデータベース プラットフォームまたは現在のプラットフォームの新しいバージョンに移動することを選択し、'insert' ステートメントを使用してすべてのデータを移動する場合、ID フィールドが失われる可能性があります。

私たちの製品では、人間が理解できるキーである主キーの隣に常に「自然キー」を使用しています。

ログ テーブルの場合など、人間が理解できる自然キーが利用できない場合は、人工キーに戻すことができます。

于 2014-12-09T09:25:58.937 に答える
3

キーを選択または設計する際に、覚えておくべき望ましい特性が少なくとも 3 つあります。シンプルさ、安定性、親しみやすさです。実際には、数字だけよりも単語や文字を覚えて操作する方が簡単であることがよくあります。そのため、一般的に、数字のみの識別子よりも英数字の識別子の方が一般的です (英数字の識別子の例: 車のナンバー プレート、航空会社のフライト番号、座席予約など)。番号、州コード、国コード、郵便番号、電子メール アドレス)。数字のみよりも英数字キーの方が使いやすいという考えを裏付ける研究や逸話的な証拠があります。また、英数字の識別子は、多くの場合、数字の識別子よりも短くなることがあります。一方、連続する数字のみの識別子は、一部のアプリケーション (請求書番号、銀行口座番号など) では非常に一般的です。

DBMS エンジン レベルのシーケンス ジェネレーターには、多くの場合、一部のアプリケーションには適さないという制限があることに注意してください。たとえば、それらを更新したり、分散データベース アーキテクチャで使用したりするのは簡単ではない場合があります。もう 1 つの一般的な制限は、テーブルごとに 1 つの「自動インクリメント」列しか許可されないことです。これにより、同じテーブルの代理キーも必要な場合にビジネス キーとして使用できなくなります。

于 2014-12-10T09:59:00.697 に答える