7

私はいくつかのデータベース抽象化レイヤーを使用していますが、それらのほとんどは、VARCHAR 250 である「文字列」や長さが 11 桁の INTEGER などの属性を使用しています。しかし、たとえば、250 文字未満の長さのものがあります。私は行ってそれを少なくするべきですか？それは本当に価値のある違いをもたらしますか？

前もって感謝します！

4

5 に答える 5

10

INTの長さは何もしません。すべてのINTは4バイトです。設定できる番号は、zerofill（そして誰がそれを使用するのか！？）にのみ使用されます。

VARCHARの長さはそれ以上のことをします。これは、フィールドの最大長です。VARCHARは、実際のデータのみが保存されるように保存されるため、長さが問題になりません。最近では、255バイト（256 ^ 2-1）よりも大きなVARCHARを使用できます。違いは、フィールド長に使用されるバイト数です。VARCHAR（100）とVARCHAR（8）およびVARCHAR（255）は、1バイトを使用してフィールド長を保存します。VARCHAR（1000）は2を使用します。

お役に立てば幸いです=）

編集
私はほとんどの場合、VARCHARを250の長さにします。とにかく実際の長さはアプリでチェックする必要があります。より大きなフィールドの場合、私はTEXTを使用します（そしてそれらは異なって保存されるので、はるかに長くなる可能性があります）。

編集
これがどれほど最新かはわかりませんが、以前は私を助けてくれました（理解してください）： http： //help.scibit.com/Mascon/masconMySQL_Field_Types.html

于 2011-04-25T19:17:14.747 に答える
2

まず、データベースは事実を保存するためのものであり、不正なデータから自身を保護するように設計されていることを思い出してください。したがって、ユーザーが名前に 250 文字を入力できないようにする理由は、ユーザーが名前以外のすべての種類のデータを入力するためです。彼らは自分のフルネーム、下着のサイズ、去年の夏に何をしたかについての小説などを載せます. したがって、データが可能な限り正確であるようにする必要があります。アプリケーションが不正なデータを保護する唯一の手段であると考えるのは間違いです。特定の列にWar in Peaceを詰め込むのに問題があったことをユーザーに伝えてもらいたいとします。

したがって、最も重要な質問は、「格納されているデータの最も適切な値は何か?」ということです。理想的には、intおよびチェック制約を使用して、値が適切な範囲 (0 より大きい、10 億より小さいなど) であることを確認します。残念ながら、これは MySQL の最大の弱点の 1 つです。チェック制約を尊重しません。これは単に、これらの整合性チェックをトリガーに実装する必要があることを意味しますが、これは確かに面倒です。

(4 バイト) の違いは (1 バイト)intにかなりの違いをtinyintもたらしますか? 明らかに、それはデータの量に依存します。行数が 10 行以下の場合、答えは明らかにノーです。100 億行になる場合、答えは明らかに「はい」です。ただし、IMO、これは時期尚早の最適化です。最初に正確性を確保することに集中する方がはるかに優れています。

テキストについては、データが中国語、日本語、または ANSI 以外の値をサポートする必要があるか (つまり、nvarchar または varchar を使用する必要があるか) を確認する必要があります。この値は、通貨コードや特定の仕様を持つ銀行コードなどの実際のコードを表していますか?

于 2011-04-25T19:35:10.407 に答える
1

MySQL ではよくわかりませんが、MS SQL では、データベースが十分に大きい場合にのみ違いが生じます。通常、私は、a) スペースの節約 (良い習慣を実践することは決して悪いことではありません) と、b) 暗黙の検証 (特定のフィールドが 10 文字を超えてはならないことがわかっている場合、なぜ 11 文字を許可するのか) のために、より小さなフィールドを使用するのが好きです。単独で 250?)。

于 2011-04-25T19:14:59.217 に答える
0

正しいフィールド サイズは、入力できる不適切なデータを制限するのに役立ちます。たとえば、電話番号フィールドがあるとします。250 文字を許可すると、多くの場合、電話番号フィールドで次のような結果になります (ランダムに取られた例ではありません)。

Call the good-looking blonde secretary instead.

したがって、最初に長さを制限することは、データの整合性ルールを適用する方法の一部です。そのため、それは重要です。

第二に、データページには非常に多くのスペースしかなく、一部のデータベースでは潜在的なレコードがデータページの幅よりも長いテーブルを作成できますが、多くの場合、データを保存するときに実際にそれを超えることはできません. これにより、突然 1 つのレコードを保存できなくなったときに、非常に見つけにくいバグが発生する可能性があります。MySql についてはわかりませんが、これが行われるかどうかはわかりませんが、SQL Server が行うことは知っており、何が問題なのかを理解するのは非常に困難です。したがって、データを正しいサイズにすることは、バグを防ぐために重要です。

于 2011-04-25T19:42:50.093 に答える
0

Rudie が間違っていると思います。すべての INT が 4 バイトであるとは限りません。MySQL では次のようになります。

tinyint = 1 バイト、smallint = 2 バイト、mediumint = 3 バイト、int = 4 バイト、bigint = 8 バイト。

ルディは、列を作成するときに括弧の間に入れた数字である「表示」を指していると思います。

年齢INT(3)

RDBMS に3 つ以下の数字を表示するように指示しています。

また、VARCHAR は (可変長の文字列) であるため、名前 varchar(5000) を宣言し、「Mario」のような名前を格納すると、7 バイトしか使用しません (データに 5 バイト、値の長さに 2 バイト)。

于 2011-04-25T19:25:57.130 に答える