5

mysqlDBの単純さとグッドプラクティスに関する質問と回答を読んだことがあります。

'clients'テーブルを持つmysqlDBがあります。追加された各クライアントには、電子メールに関して一意の電子メールがあります。C++ Builderを使用すると、自動インクリメントされたidフィールドが原因でレコードを追加する際に問題が発生します。 DBEXPRESSを使用して新しい行を追加します。

自動インクリメントされたIDをスキップしてみませんか？（自動インクリメントされた）IDのないテーブルを作成し、電子メールを一意のキーとして使用することをお勧めしますか？これでDBEXPRESSの問題は解決します。

4

2 に答える 2

3

いいえ：主キーとして電子メールを使用しないでください。理由はいくつかあります。

  • メールアドレスを持っていない人を保存することはできません。さまざまな理由で保存したい場合があります。
  • キーが非常に「ワイド」になるため、外部キーもワイドになり、I / Oページあたりのインデックスエントリが少なくなるため、ディスクスペースが大幅に浪費され、クエリが遅くなります。
  • 人々は自分の電子メールアドレスを変更する可能性があります-それが主キーである場合、どのように処理しますか？
  • ほとんどのデータベースコーダーは、と呼ばれる自動インクリメントキーがあることを期待しているため、クエリの保守は直感的ではありませんid。業界標準に準拠することは良い習慣です。
于 2012-09-23T09:27:02.240 に答える
1

概念的には、はい、人工的な一意のキーを生成しない（または少なくともそれらのインスタンスを制限する）ことをお勧めします。そしてe-mail、その自然なユニークな主要な目的を果たします。

ただし、気になるのはパフォーマンスです。IDとして整数を使用すると、クエリを実行するときに非常に便利であり、長い文字列よりも整数を検索する方がはるかに高速です...電子メールアドレスを使用してデータベースからユーザーを取得するだけでもかまいません。ただし、複数の結合を含む複雑なクエリがある場合は重要です。

また、クライアントに関する情報を複数のテーブルに格納する場合、他のテーブルへの外部キーは電子メールアドレスになります。これは、電子メールアドレスを複数回保存することを意味します。これにより、クライアントがいつか電子メールを変更することを決定した場合に、すべてを最新の状態に保つことが非常に困難になります。

于 2012-09-23T09:25:33.527 に答える