（n）varchar列のためにどのサイズを選ぶべきか？

StackOverflow https://stackoverflow.com/questions/1261441

質問

で TDWTFに関するわずかに加熱された議論 dbのvarchar列のサイズについて疑問が生じました。

たとえば、人の名前を含むフィールド（名前、姓なし）を取ります。それはそれほど長くないことを見るのは非常に簡単です。ほとんどの人には10文字未満の名前があり、20を超える人はほとんどいません。たとえば、varchar（50）などのコラムを作成すると、これまでに遭遇するすべての名前を確実に保持します。

ただし、ほとんどのDBMでは、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

L + 1バイト列値が0〜255バイトを必要とする場合、値が255バイト以上を必要とする場合はL + 2バイト

Oracleのドキュメントが見つかりません。他のDBMと仕事をしていません。しかし、私はそれがそこに違うと信じる理由はありません。

役に立ちましたか？

解決

私はオラクルのためにしか話せません。 VARCHAR2（50）とVarchar2（255）は、値「スミス」を入力すると、まったく同じ量のスペースを占め、同一に実行します。

ただし、一般的に、すべてのテキスト列をVarchar2（4000）として宣言することを回避することが良い考えではない理由は、列の長さが事実上別の制約であるためです。制約はビジネスルールのデータベース実装であるため、データベース側で定義する必要があるものです。

例として。列のチェック制約を定義して、受け入れる値が「Y」と「n」のみになるようにします。これにより、アプリケーションは「Y」と「n」、さらには「1」と「0」に対処する必要がなくなります。チェック制約により、データが予想される標準に適合します。アプリケーションコードは、対処しなければならないデータの性質について有効な仮定を行うことができます。

列の長さの定義は同じボートにあります。 「ABC123ZYX456」のエントリを受け入れたくないので、何かをvarchar2（10）であると宣言します（何らかの理由で！）

オーストラリアでは、「ニューサウスウェールズ」や「南オーストラリア」でタイピングする人が欲しくないため、州の列をvarchar2（3）と定義しています。列定義は、それらを「NSW」と「SA」として入力することをほとんど強制します。その意味で、Varchar2（3）は、実際にチェックイン（「NSW」、「SA」、「VIC」など）を指定するのとほぼ同じくらいのチェック制約です。

要するに、適切な列の長さは、ビジネスルールをエンコードする方法です。それらは別の形の制約です。それらは制約のすべての利点をもたらします（そして同じ欠点の多くに苦しんでいます）。そして、彼らは、「適切な」制約も役立つ「データの清潔さ」のある程度にも保証します。

私は、クライアントアプリにこの種のものを貼り付けるのが最善であるという議論も購入しません。アプリを使用している20,000人がいます。これは20,000人の更新です。 1つのデータベースがあります。これは1つの更新です。 「クライアントアプリを変更するのが簡単」という引数は、Trueの場合、データベースがクライアントコードで処理されているすべての巧妙なロジックを備えた巨大なビットバケットとして扱われることを意味します。それは大きな議論ですが、すべてのRDBMSがデータベース自体で制約などを定義できるようにするため、少なくともそのような基本的なロジックがバックエンドに属しているという価値のあるケースがあることは明らかです。

他のヒント

クエリオプティマイザーを聞いたことがあります します リファレンスは見つかりませんが、Varcharの長さを考慮してください。

Varcharの長さを定義することは、意図を伝えるのに役立ちます。より多くのコントレストが定義されているほど、データの信頼性が高くなります。

では、なぜ人々は自分の列をできるだけ小さくしようとするのでしょうか？ 私はそれらをできる限り小さくすることを信じていませんが、適切にサイズを変更します。 （n）varcharsを大きくするのではなく小さくする理由：

1）より大きなフィールドでは、データベースを使用するすべてのクライアントがフルサイズを処理できる必要があります。たとえば、各フィールドごとに255文字の米国住所を保持しているシステムを撮影してください。（参照するTDWTFに似ています。

  • ファーストネーム
  • 苗字
  • 住所1
  • 住所2
  • 街
  • 州
  • 郵便番号

これで、データ入力画面は、フィールドごとに255文字を許可および表示する必要があります。大変ではありませんが、大きなフィールド印刷の請求書で見栄えがよくないため、大きなフィールドを処理するためにラインブレイクロジックが必要になります。ツールに応じて、それほど難しくありません。

しかし、これらのフィールドごとに255文字またはそれらのフィールドのいずれかに255文字を持つ可能性のあるエンベロープのアドレスをフォーマットする問題を望んでいません。フィールドが収まるには長すぎる場合、あなたは切り捨てますか？偉大な誰かには、「ハウスナンバーストリート番号...何とか何とか...アパート番号111」のアドレスライン1があります。そして、あなたは重要なアパート番号を取り除きます。あなたは包むつもりですか？いくら？封筒のスペースの小さな箱に収まらない場合はどうなりますか？例外を提起し、誰かに手紙を持っていますか？

2）Varchar（50）対Varchar（255）に保持されている10文字のデータはサイズや速度に影響を与えませんが、255文字を使用すると、より多くのスペースをとることができます。そして、すべてのフィールドがそれほど大きい場合は、SQL Server 2000でサイズ制限を押すことができます。誰かが実際に利用可能なすべてのキャラクターを実際に使用した場合に発生するようにチェーン。

3）インデックスには、より厳格なサイズの制限があり、葉のページがあります。 Varcharsを大きすぎると、インデックス、特に複合インデックスを排除することができます。

一方、私は自分の住所に長い行1を持っており、完全なものを入力できないWebサイトに不満を感じています。

1つの重要な違いは、任意に大きな制限を指定することの間です[例： VARCHAR(2000)]、および制限を必要としないデータ型を使用する[例： VARCHAR(MAX) また TEXT].

PostgreSQLは、すべての固定長を基にしています VARCHARs無制限 TEXT タイプし、動的に決定します 値ごと ページ外で保存するなど、値を保存する方法。この場合の長さ指定子は実際には単なる制約であり、その使用は実際には落胆しています。 （ref）

他のDBMSでは、ユーザーが「無制限」、ページ、ストレージ、通常は関連するコストやパフォーマンスが必要な場合に選択する必要があります。

使用に利点がある場合 VARCHAR(<n>) 以上 VARCHAR(MAX) また TEXT, 、その結果、あなたはの値を選択する必要があります <n> テーブルを設計するとき。テーブル行の最大幅、またはインデックスエントリがあると仮定すると、次の制約が適用する必要があります。

  1. <n> より少ないか等しくなければなりません <max width>
  2. もしも <n> = <max width>, 、テーブル/インデックスには1列のみを持つことができます
  3. 一般的に、テーブル/インデックスにはしかありません <x> （平均して）列 <n> = <max width> / <x>

したがって、そうです いいえ の値 <n> 制約としてのみ機能し、 <n> デザインの一部でなければなりません。 （DBMSに厳しい制限がない場合でも、特定の制限内で幅を維持するパフォーマンスの理由があるかもしれません。）

上記のルールを使用してaを割り当てることができます 最大 の値 <n>, 、テーブルの予想されるアーキテクチャに基づいています（将来の変更の影響を考慮して）。ただし、定義する方が理にかなっています 最小 の値 <n>, 、予想に基づいています データ 各列に。ほとんどの場合、あなたは最も近い「ラウンド番号」に拡張します - 例えば、あなたは常にどちらかを使用します VARCHAR(10), VARCHAR(50), VARCHAR(200), 、 また VARCHAR(1000), 、どちらに最適なのか。

私の意見では、これに対する簡単な答えは、その列をインデックスキーとして使用できないという事実です。インデックスが必要な場合は、基本的にFullTextを使用することを余儀なくされています...これはVarchar（Max）列を使用することです。いずれにせよ、「右サイズの」列は、任意のインデックスを適用したい場合はいつでも、非常に理にかなっています。可変長列の更新は、これらが配置されておらず、ある程度の断片化を引き起こす可能性があるため、費用のかかる操作になる可能性があります。

MS SQ-Serverに関して。

I'll answer your question with a question: If there is no difference to the DBMS between a varchar(50) and a varchar(255), why would the DBMS let you make a distinction? Why wouldn't a DBMS simply say "use varchar for up to xxx characters, and text/clob/etc. for anything over that." Sure, perhaps Microsoft/Oracle/IBM might keep the length definition for historical reasons, but what about DBMS' like MySQL which has multiple storage backends- why does every one implement definable character column lengths?

If you are going to print labels you usually want the string to be no longer than 35 characters. This is why you want some control on the size of the Varchar that you are going to use to accept the lines that are going to be used to print labels.

If you allow the data length to be over 255 and someone links to the data through MS Access the data is not able to be used to join tables (comes in as a memo field). If the data is exported to excel it will be limited to 255 characters per field. Compatibility with other programs should be considered when creating data sets.
Data quality control is all about controlling the data entering your environment. What do you need to store that is over 255 characters? There are times that data needs to be over 255 characters, but they should be far and few between and should be used as supportive supplemental information for a field that can be used for analysis

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top