128/256/4096バイトオフセットに丸められたVARCHARサイズを使用する理由はありますか？

データベーススキーマでは、VARCHARサイズがバイトオフセット128/256または4096に丸められることがよくあります。これも以前に行ったことがあり、その背後にあるアイデアはおそらく効率的なものでした。

しかし、今日そうする正当な理由はまだありますか？最近ではVARCHARサイズとして '50'、 '100'、または '200'をよく使用します。これらはより自然で、通常はユーザーに対する検証チェックでも表示されるためです。

私が考えることができる唯一の合理的な説明は次のとおりです。DBMSが列の値を連続して格納し、サイズが2の累乗に丸められていない場合、一部の要素をハード上の2ページに「分割」する必要がある場合がありますドライブ（たとえば、ページnの最初の10バイトとページn + 1の次の40バイト）。場合によっては、1つではなくハードドライブから2つの読み取りが発生する可能性があります。

@Jan Hudecのポイントは、多くのプログラマーが「128」または「256」を「素敵なラウンド数」と考えており、137、19、100などの奇数よりも自然な選択になっているという点です。

一般に、これらの列の長さに理由はありません。varchar（100）列とvarchar（128）列のパフォーマンスの改善はありません。

ただし、使用しているデータベースシステムを再確認して、制限やその他のベンダー固有の注意事項をさらに明確にします。

たとえば、SQL Serverのデータベースシステム制限の良い例を次に示します。

http://msdn.microsoft.com/en-us/library/ms186981.aspx

行の全長は、個々の列の長さよりも重要です。

DBMSであるかコンパイラであるかは思い出せませんが、配列と列の長さに2のべき乗を使用することを学習したことを（かなり前に）思い出します。実装がビットシフトを使用できるため、「高速」であるという正当化がありました。もう成り立つかどうかは未解決の問題です。まだ有効であるかどうかは誰にも分かりますか？

ところで、私は列幅を一律の数値b / cに移動しました。ユーザーにchar制限が256文字であることを伝えるのは奇妙です。

また、一部の非常に古いデータベースでは、文字幅が256列に制限されていました。

行全体のサイズが2のべき乗である場合にのみストレージの効率が実際に表示されるため、おそらく重要ではありません。2のべき乗を維持すると、行サイズほとんどのネイティブデータ型は（データベースに応じて）2のべき乗のサイズになる傾向があるため、2の累乗になりますが、私はそれを厳格なルールにしません。

大きな（4K以上の）列を操作している場合は、列を個別に保存し、1つのストレージブロック（データベースがディスク上のストレージに使用するものは何でも）に収まるようにサイズを調整できるため、より意味がありますあなた何か。

すべてのDBMSシステムに精通しているわけではありませんが、Oracleのストレージの最小の「物理」単位は、デフォルトでサイズが2KBの「ブロック」です。2の累乗で列のサイズを変更することは、ストレージブロックに適切に収まるように行のサイズを変更するより大きな方法の一部です。1行がブロックサイズよりも1バイト多く必要になるように列のサイズを変更すると、2ブロックを割り当てる必要があり、行も2ブロックにまたがるため、各行を1ブロックに収めることができる場合よりも読み取り、挿入、スキャンに時間がかかります（各ブロックに1行のみがあります）。少なくとも、それが歴史的な理由です。最近では、ほとんどの人がこの方法を準最適化と考えています。