3

私は約 2 年間 SQL を扱ってきましたが、常に頭の中にありました。

ベストプラクティスは、列の長さを期待どおりに割り当てると言います

SQL は主キー専用の特定の行を必要としますが、A_i フィールドのベストプラクティスでもあります...しかし、それを割り当てる長さは? 空白のままにすると、デフォルトで11になり、 999,999,999を表します

これは問題ないように思えますが、ベスト プラクティスには、データベースから実際に何も消去しないことも記載されています。削除されたことを表すために 0 または 1 を追加するだけです。これは、アーカイブ/回復の目的のためです.また、ユーザーがクリアしたいものの監査にも使用できます..

次の例を見てください。

私は、データベースから何も削除しないというベストプラクティスに従って、何年もの間存在している Web サイトを持っています。データベース/Web サイトのトラフィックが非常に多く、1 日に多数のユニーク ユーザー/訪問者がいます。

ここで、SQL のデフォルトの長さである 11 のままにしておくと、テーブルが最大長に達し、別のユーザーが登録しようとするとどうなるでしょうか? エラーがスローされて続行されないため、新しいユーザーには少量のダウンタイムが発生します。理由は、データベース管理者が SQL にログインして長さを変更する必要があるためです..これはそれほど手間ではありませんが、IS初期の開発中に避けることができる努力..

私がしていることは、テーブルを作成するときに255の長さを与えることです。これは、心の奥底で「これは良い習慣ではない」と言っていますが、上記の例の非常にわずかな可能性を回避します。

text指定された長さを持たないフィールドと比較すると、なぜこれは A_I フィールドに関して同じにできないのでしょうか。

誤解しないでください。利用可能なデータ型を完全に理解しています。

私はグーグルとSOの両方で多くの調査を行いましたが、結果は現在の長さを増やすためにテーブルを変更することについての質問を指摘しています. これは私が求めているものではありません。

全体：

全体として、私が尋ねようとしていることは次のとおりです。A_I フィールドの理想的な長さは? 長さが最大になった場合にエラーがスローされるわずかなリスクを最小限に抑えるだけでなく、ベストプラクティスも念頭に置いてください。

4

2 に答える 2

4

理由は簡単です
。ID は主キーであるため、期待どおりの ID である必要があります。
varchar を指定すると、インデックスのサイズが大きくなり
、読み取りと書き込みの両方のパフォーマンスが低下するという欠点があります。

int(11) .. 99,999,999,999 までは格納されません。
2,147,483,647 までしか保存できません。

unsigned に設定すると
、4,294,967,295 のレコード (40 億!) を許可できます。

Facebook のユーザー数はわずか 10 億人を超えています。
だから、誰でもすぐに4倍のユーザーベースを持つことができるとは思いません...

この記事では、いくつかのベスト プラクティスについて詳しく説明しています。

http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

  1. 列が小さいほど高速
  2. integer は固定長ですが、varchar は固定長ではありません
  3. 結合に同じ列タイプを索引付けして使用する
于 2013-04-06T21:43:56.343 に答える
1

アプリケーションまたはシステムを分析します。推定 1 日あたり何人のユーザーが登録しますか? 1年当たり？これを知ったら、どの程度「安全」になりたいかを決定します-これを変更する必要なしにシステムを何年実行するかという観点から。100 年で十分だとしましょう。したがって、予想される年間ユーザー登録数に 100 を掛けて、PK がその多くの値に対応するのに十分な大きさであることを確認してください。

于 2013-04-06T21:26:03.953 に答える