問題タブ [varchar]

MySQLはvarcharフィールドをどのように保存しますか？次のパターンが適切なストレージサイズを表していると想定できますか？

1,2,4,8,16,32,64,128,255（最大）

例による説明。20文字のvarcharフィールドがあるとします。MySQLはこのフィールドを作成するときに、基本的に32バイトのスペースを予約しますか（バイトかどうかはわかりません）、20バイトしか入力できませんか？

巨大なテーブルのディスク容量を最適化するのが心配だと思います。

oraclevarchar値を数値に変換するにはどうすればよいですか

例えば

exception_value列の値をテストしたい

ジョンは私が使用CHARACTER VARYINGする場所で使用しますVARCHAR。私は初心者ですが、彼は熟練者です。これは、私が知らない何かがあることを示唆しています。

PostgreSQLのCHARACTER VARYINGとVARCHARの違いは何ですか?

複数のコース、本、およびジョブで、「短い」テキストのデフォルトの一種としてVARCHAR（255）として定義されたテキストフィールドを見てきました。良いラウンド数である以外に、255の長さが頻繁に選択される正当な理由はありますか？それは、正当な理由があった過去のある時期からのホールドアウトですか（今日適用されるかどうかにかかわらず）？

もちろん、弦の最大の長さをどういうわけか知っていれば、より厳しい制限がより理想的であることを私は理解しています。ただし、最大長がわからないことを示すVARCHAR（255）を使用している場合は、それが「短い」文字列であることだけを示します。

注：この質問（varchar（255）v tinyblob v tinytext）を見つけました。これは、VARCHAR（n）がn <=255の場合はn +1バイトのストレージ、 n >255の場合はn +2バイトのストレージを必要とすることを示しています。これが唯一の理由ですか？VARCHAR（256）と比較して2バイトしか節約できず、VARCHAR（253）と宣言することで、さらに2バイトを簡単に節約できるため、これは一種の恣意的なようです。

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 の両方を使用します。

TDWTF に関するやや白熱した議論の中で、DB 内の varchar 列のサイズに関する疑問が生じました。

たとえば、個人の名前 (名前のみで姓は含まれない) を含むフィールドを考えてみましょう。それほど長くないことは容易にわかります。ほとんどの人の名前は 10 文字未満であり、20 文字を超える人はほとんどいません。たとえば、varchar(50) という列を作成すると、これまでに遭遇したすべての名前が確実に保持されます。

ただし、ほとんどの DBMS では、varchar(50) を作成しても varchar(255) を作成しても、サイズや速度に違いはありません。

では、なぜ列をできるだけ小さくしようとするのでしょうか? 場合によっては、実際に文字列の長さに制限を設けたい場合があることは理解していますが、ほとんどの場合、そうではありません。そして、非常に長い名前を持つ人のまれなケースがある場合にのみ、より広いマージンが有益になります.

MSSQL の場合:http://msdn.microsoft.com/en-us/library/ms176089.aspx

ストレージサイズは、入力されたデータの実際の長さ + 2 バイトです。

MySQL の場合:http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

列の値に 0 ～ 255 バイトが必要な場合は L + 1 バイト、値が 255 バイトを超える可能性がある場合は L + 2 バイト

Oracle のドキュメントが見つからず、他の DBMS を使用したことがありません。しかし、私はそれがそこで違うと信じる理由はありません。

重複の可能性:
すべてのテキストベースのフィールドにジェネリック varchar(255) を使用することの欠点はありますか?

MYSQL では、VARCHAR フィールド タイプの長さを選択できます。可能な値は 1 ～ 255 です。

しかし、VARCHAR(20) の代わりに最大値である VARCHAR(255) を使用すると、どのような利点がありますか? 私の知る限り、エントリのサイズは、挿入された文字列の実際の長さにのみ依存します。

サイズ (バイト) = 長さ + 1

したがって、VARCHAR(255) フィールドに「例」という単語がある場合、8 バイトになります。VARCHAR(20) フィールドにある場合は、8 バイトもあります。違いはなんですか？

あなたが私を助けてくれることを願っています。前もって感謝します！

免責事項：私はSQLとデータベース全般に非常に慣れていません。

最大32文字のテキストデータを格納するフィールドを作成する必要があります。「 」は、データに正確に32文字VARCHAR(32)あることを意味しますか？ヌル終了のために追加の文字を予約する必要がありますか？

簡単なテストを行ったところ、これはWYSIWYGバッファーのようです。しかし、実際に何をしているのかを知っている人から具体的な答えを得たいと思いました。

私はC[++]のバックグラウンドを持っているので、この質問は私の頭の中で警鐘を鳴らしています。

VARCHAR列に完全に格納可能なデータが含まれていると思われるNVARCHAR列がたくさんあります。ただし、列のタイプをVARCHARに変更して、最善を期待することはできません。何らかのチェックを行う必要があります。

データは静的であり（将来変更されない）、列にインデックスが付けられ、実際の（nvarchar）インデックスと比較して小さい（varchar）インデックスの恩恵を受けるため、変換を実行したいと思います。

簡単に言えば

そうすれば、エラーや警告は表示されません。Unicodeデータは切り捨てられるか失われます。

どうすれば確認できますか？

単一の一意のVARCHAR（512）フィールドを持つテーブルがあります。この最初のテーブルへの外部キー参照を別のテーブルに保持させたい。どちらのテーブルもInnoDBを使用しています。2番目のテーブルにVARCHAR（512）キーを追加し、それに外部キー制約を追加すると、512バイトの長さのデータが2回保持されますか？

もしそうなら、varchar自体ではなく、インデックスへの参照のみを保持する方法はありますか？

要するに、私の質問は、InnoDBに長いVARCHARフィールドへの外部キーを保持する効率的な方法はありますか？

どうもありがとうございます、

ヤニフ