重複の可能性:
すべてのテキストベースのフィールドにジェネリック varchar(255) を使用することの欠点はありますか?
MYSQL では、VARCHAR フィールド タイプの長さを選択できます。可能な値は 1 ～ 255 です。
しかし、VARCHAR(20) の代わりに最大値である VARCHAR(255) を使用すると、どのような利点がありますか? 私の知る限り、エントリのサイズは、挿入された文字列の実際の長さにのみ依存します。
サイズ (バイト) = 長さ + 1
したがって、VARCHAR(255) フィールドに「例」という単語がある場合、8 バイトになります。VARCHAR(20) フィールドにある場合は、8 バイトもあります。違いはなんですか？
あなたが私を助けてくれることを願っています。前もって感謝します！
チェックアウト: Varchar のリファレンス
要するに、長さのプレフィックスに別のバイトが必要になる VARCHAR で 255 のサイズを超えない限り、大きな違いはありません。
長さは、列に格納されているデータに対する制約を何よりも示しています。これにより、列の MAXIMUM ストレージ サイズも本質的に制限されます。私見、長さはデータに関して意味があるはずです。# 社会保障を保管する場合、長さを 128 に設定しても意味がありませんが、実際に保管するのが SSN だけであれば保管に費用はかかりません。
パフォーマンスに関係なく、最大値より小さい値を選択する正当な理由は多数あります。サイズを設定すると、保存しているデータのタイプを示すのに役立ち、最後のガスプ形式の検証としても機能します。
たとえば、英国の郵便番号を保存する場合は、8 文字しか必要ありません。この制限を設定すると、保存するデータの種類を明確にするのに役立ちます。255 文字を選択すると、問題が混乱するだけです。
mySQLについてはわかりませんが、SQL Serverでは、使用される合計バイト数が実際にレコードに格納できる合計バイト数よりも大きくなるようにフィールドを定義できます。これは悪いことです。遅かれ早かれ、制限に達し、データを挿入できない行が表示されます。
行サイズの制限を考慮してデータベース構造を設計することをお勧めします。
さらに、はい、最大値が 10 であるフィールドに 200 文字を入力することは望ましくありません。入力した場合、ほとんどの場合、データが正しくありません。
あなたは、アプリケーション レベルでそれを制限することができると言いました。しかし、データは 1 つのアプリケーションからデータベースに取り込まれるわけではありません。複数のアプリケーションで使用される場合もあれば、データがインポートされる場合もあれば、クエリ ウィンドウから手動で修正される場合もあります (たとえば、すべてのレコードを更新して価格に 10% を追加します)。これらの他のデータ ソースのいずれかが、アプリケーションに設定したルールを認識していない場合、データベースには不適切で役に立たないデータが含まれます。データベース レベルでデータの整合性を強制する必要があります (データを入力する前にチェックすることもできます)。そうしないと、整合性がなくなります。さらに、私の経験では、データベースを設計するのが面倒な人は、実際にアプリケーションに制限を加えるのも怠惰なことが多く、データの整合性チェックがまったく行われていません。
彼らは、データの整合性がないデータベース、つまり役に立たないという言葉を持っています。
意味上の違いがあります (それが唯一の違いだと思います): varchar(20) に 30 個の非スペース文字を入力しようとすると、エラーが発生しますが、varchar(255) では成功します。したがって、これは主に追加の制約です。
より大きなエントリを許可したい場合、またはおそらくエントリのサイズを制限したい場合。
たとえば、first_name を VARCHAR 20 として持っているかもしれませんが、20 では十分なスペースがないため、street_address を VARCHAR 50 として持っているかもしれません。同時に、その値がどれだけ大きくなるかを制御したい場合があります。
つまり、テーブル (および場合によってはインデックス/インデックス エントリ) が大きくなりすぎるのを防ぐために、理論上は特定の値の上限を設定しました。
固定幅の CHAR も使用できますが、より小さくできる VARCHAR とは異なり、CHAR は値を埋め込みます (ただし、これにより SQL アクセスが高速になります。
データベースの観点から言えば、パフォーマンスに違いがあるとは思えません。
ただし、使用する長さに関する決定の多くは、達成しようとしていることと、必要なデータだけを受け入れるようにシステムを文書化することに帰着すると思います。