多くのデータベース スキーマは、次の標準に従っているようです。
(2^n)-1大きいフィールドの場合:
varchar(511)
varchar(255)
varchar(127)
...小さい方は(2^n)
varchar(64)
varchar(32)
varchar(16)
varchar(8)
(2^n)-1 という数値が使用される理由は理解できますが、理解できないのは、小さなフィールドまでトレンドを継続する必要がない理由です。
例えば
varchar(63)
varchar(31)
varchar(15)
varchar(7)
これには何か理由があるのでしょうか、それとも単にリターンが大幅に減少しただけなのでしょうか?
ディスクまたはメモリ上のブロックの配置に関しては、長さ 2^n の方が優れていた昔のことを覚えています。整列ブロックの方が高速でした。今日、「ブロック」のサイズは大きくなり、メモリとディスクは、非常に大きなブロックを除いて、アライメントを無視するのに十分高速です。（「非常に大きい」が今日何を意味するにせよ....）
今日では、そうするのが伝統的です。
そして、私の有名な格言であるもう 1 つの理由は、10 種類の人しかいないということです。
そして 2^n -1 はメルセンヌ素数の候補です。だからオタクすぎる…
私は、それが本当に重要ではないときに、プログラマーが空中から数字を選んでいるだけだと思います.
たとえば、「メモ」フィールドに制限を設ける必要がある場合、プログラマーは 127 または 255 をラウンド番号と考えるかもしれませんが、プログラマー以外はおそらく 100 または 200 文字をラウンド番号として選択するでしょう。
「-1」の傾向が小さいフィールドと大きいフィールドで異なる方法で使用されているのを見てきたため、何とも言えません。ただし、開発者/データベースのOCDにすぎないと思います。「きれいさ」ではなくビジネスルールに基づいて実際にフィールド長を決定する必要がある場合に、常に「丸め」の数値が必要です。
リターンが減少するだけでなく、文字列型に任意の制限を設定すると、問題を解決するよりも問題を引き起こす可能性が高くなります。
それが実際にビジネス上の制約である場合は、長さに対して TEXT タイプ (または類似のもの) と CHECK 制約を使用し、適用しようとしているビジネス上の制約に従って数値を選択します。
いずれにせよ、DBMS はおそらく TEXT 型のストレージを varchar(x) と同じように実装します。そうでなく、本当に気にする場合は、特定のシステムの内部ストレージ戦略を調査し、varchar に利点があるかどうかを検討する必要があります。
実は、そのような「トレンド」は初めて聞きました。私のvarcharフィールドは、必要な限り常にあります。
特に理由はないと言っていいでしょう。開発者の好みです。
カウント 2^N または 2^N-1 のいずれかで、フィールドのサイズをそのように設定している理由がちょっと想像できません。SQL Server の観点からは、特定の理由というよりも、SQL がそのデータをページ レベルで格納する方法についての誤解のように思えます。
2^N などの使用に基づく式よりも、タイプ、潜在的なオフページ ストレージ (SLoB / LoB)、および行/ページ + サイジングによるビジネス ニーズへの対応に注意を払います。