VARCHAR(256) の代わりに VARCHAR(255) が常に使用されていますが、VARCHAR(15) の代わりに VARCHAR(16) も使用されています。これは私には矛盾しているようです。VARCHAR の長さを格納するために余分なバイトが使用されている場合、この規則は 2、4、8 のような短い長さにも適用され、代わりに 1、3、7 になるべきではありませんか?
それとも、何かが完全に欠けていますか？
つまり、12 を超えることはないとわかっている数値がある場合、代わりに VARCHAR(15) または VARCHAR(16) を使用する必要がありますか? VARCHAR(12) と同じ量のスペースを使用するためですか? その場合、どちらを使用しますか? 15か16？256 に近づくと、このルールはまったく変更されますか?
プロジェクトに応じて、MySQL と SQL の両方を使用します。
つまり、12 を超えることはないことがわかっている数値がある場合、代わりに VARCHAR(15) または VARCHAR(16) を使用する必要がありますか?
いいえ！varchar(12) を使用します (または、長さがかなり一定の場合は char(12) を使用することもできます)。
昔々、格納された最初のバイトがフィールドの長さを示していたため、一部のシステム ( 5.0.3 より前の MySql を含む)では varchar 型が 255 文字に制限されていました。この制限を考えると、合理的な量のテキストを許可したい開発者は、別のデータ型に完全に移行するのではなく、255 を選択します。
ただし、データのサイズがわかっている場合は、データベースに正確にそのサイズを使用してください。
奇数偶数とは関係ありません。
歴史的に、さまざまな DBMS で 255 文字が多くの場合、a の最大長でしたVARCHAR。当時 (Large Object)ではないフィールドの長さ制限LOBは 255 バイト (1 バイト int) でした。そのため、最初のバイトはフィールドの長さ (0 ～ 255) を格納するために使用され、残りのnバイトは文字用に使用されました。だからよく見かけますVARCHAR(255)。
フィールドが 12 を超えることがない場合は、 を使用しますVARCHAR(12)。
元の問題は、一部のシステムでは VARCHAR(...) が 255 に制限されていたことだと思います。これは、1 バイトを使用して実際の長さをエンコードすると、255 までの長さしか表現できないためです。
VARCHAR(16) / VARCHAR(15) これらの起源を連想させる可能性が最も高いですが、2 つの値に特別なことは何もありません。