DBの定義のサイズを大きくし過ぎると問題ある？

データベースとしては基本的な話になると思いますが、ご返答よろしくお願いいたします。

例えば日本人の名前はどう考えてもせいぜい漢字10文字で収まるため、名前を入力するためのDB定義は、nvarchar(20)などと少し大きめに設定すると思います。私もこれまでは当たり前のようにそうしてきました。

しかし、nvarchar型の最大サイズは4000なので、全ての項目でnvarchar(4000)としてしまえばいいような気がするのですが……誰もしてないところを見るとやはり何か問題があるのでしょうか？それはどんな問題なのでしょうか？

No.3 ベストアンサー 回答者： Picosoft 回答日時： 2013/10/25 14:57

SQL Serverの話ですよね？

> ntextの代わりにnvarchar(4000)を使う
そういうことでしたらそうしてください。
ただし、インデックスに使わないのであればnvarchar(max)の方がよいでしょう。

http://technet.microsoft.com/ja-jp/library/ms187 …
> ntext 、text、および image の各データ型は、将来のバージョンの Microsoft SQL Server で削除される予定です。
　(中略)
> 代わりに、nvarchar(max)、varchar(max)、varbinary(max) を使用してください。


で、本題の「nvarcharを使うときはとりあえずnvarchar(4000)でいいんじゃないか？」という話ですが、
1列または1レコードのサイズが大きすぎるとこんな落とし穴があるようです。
クエリ関連
http://msdn.microsoft.com/ja-jp/library/ms345371 …

キー・インデックス関連
http://technet.microsoft.com/ja-jp/library/ms163 …
http://technet.microsoft.com/ja-jp/library/ms143 …

このあたりのことも理解した上でサイズを決めた方が良さそうです。

この回答への補足

あ、すみません、SQLServer2003での話でした。
2003だからなのかわかりませんが、
私の環境では(max)というのは使えないようです……

補足日時：2013/10/25 15:58

この回答へのお礼

ご回答ありがとうございます。
やはり無意味に長すぎるのは良くないんですね。
リンク先を熟読して設定したいと思います。

お礼日時：2013/10/25 15:57

No.2 回答者： naktak 回答日時： 2013/10/25 13:52

・1レコードに対する格納領域がそれだけ必要になる。

(たった20バイトしか入らないのに、領域としては4000バイト確保する羽目に)
・インデックスに係る領域がそれだけ必要になる。

この回答へのお礼

今回、ntextの代わりにnvarchar(4000)を使うことで問題があるのかなと思って質問しました。領域というのは、SQLサーバのメモリのことでしょうか？それともストレージですか？ntextだと領域はどれくらい確保するのでしょうか？

お礼日時：2013/10/25 14:08

No.1 回答者： lupin-333333 回答日時： 2013/10/25 13:43

＞nvarchar型

それが当たり前のデーター型だとは知らなかったが、逆になんでデーターベースにデーター型があるか、ご存知でしょうか？

JavaScript言語みたいに、何でも格納出来た方が便利だと思いますけどね。その辺まるっきり考えた事無いでしょう。


よく言われるのが、通貨型と言うデーター型。これが在ると無いとでは、販売管理ソフトの設計が違ってくる。当然、ＡＴＭなどの金融系は無いとこまる。

では、なぜあった方が便利なのか？　それは、通貨計算が便利だからです。また、時間などでもそうですが、フォーマットに合わないデーターはＤＢ側で拒否できるからです。そうするとＤＢの信頼性が上がるわけです。

今みたいに、計算にほぼくらいが無い時代ならともかく、１９６０年代の頃は、ＤＢの信頼性はそんなに高くありませんでした。それはチップ自体の信頼性が今ほど高い物ではなかったからです。なので、アポロ１１号は科学的に、到達していない。と言う結論を出す科学者もいます。

何せ、あの時代のＬＳＩの信頼性はとても低く、振動とＧに絶えられる物ではなく、その信頼性を上げたのがアポロ計画だった、と言われるくらいでしたね。今では当たり前になっている、基盤を樹脂で固めるなんて事を、その計画があったか生まれたような物です。それで、誤計算がなくなったと言えます。

型を決めて、大きさを決める。このことのよって、底辺でデーターの整合性を図る事ができる。大きさが決まっていないと、プログラムにより、抜け道があった場合、違うデーターが誤って格納されてしまうわけです。これは、例えば文字化けした物がはいった場合、これをチェックする機能がプログラムに無いと、そのままＤＢに登録してしまうわけです。

しかも、大型のシステムだとＡＰＩ、ＳＰＩ化され、いろんな経路をとおってＤＢにアクセスされます。設計管理者の思惑とは違うソフトでＤＢにアクセスされてしまうわけです。そこでＤＢに最初から決まりごとがあれば、はじく事ができる。


あなたのように個人レベルならいいが、大型のＤＢには、まったく知らない人がアクセスします。そのアクセスはエンドユーザーレベルではなく、管理者レベルでアクセスするわけです（ソフト開発者）。例えばＡＴＭですよね。

それと、多くのＤＭＢＳは最初からメモリーバッファーを用意しますが、最適化すると、ＤＢエンジンのメモリーの使い方も代わってきます。それらはチューニングのカテゴリーになりますが、業務用の（ＡＴＭとか）ＤＢになると、１文字のメモリー使いでも、きにしないと、パフォーマンスにしびあに影響します。１日に何十万アクセスのＤＢを扱うようになれば、わかると思います。また、１００万レコード以上のＤＢを扱えばわかるかと。

この回答への補足

今回、ntextの代わりにnvarchar(4000)を使うことで問題があるのかなと思って質問しました。なので統合性については考える必要がありません。

補足日時：2013/10/25 14:06