なぜvarcharデータ型がまだあるのですか？

私のデータベースの多くには、varcharとして定義されたフィールドがあります。私はアメリカに住んで働いているので、これはそれほど問題ではありませんでした（存在する唯一の言語は「アメリカ人」です。ahem）

約5年間データベースを操作した後、最終的にvarcharフィールドの性質が限られているという問題に遭遇し、nvarcharとしてデータを保存するためにフィールドを変更する必要があります。テーブルに別の更新を行い、varcharフィールドをnvarcharに変換しなければならなかった後、私は考えました-なぜこのようにまだ行うのですか？私はずっと前から、新しいテキストフィールドをすべてvarcharではなくnvarcharに定義するという精神的な決定をしました。これは、10年前に学校にいたときに教科書から学んだことです。

2011年で、昨年SQL Serverの新しいリリースがありました。代わりにnvarcharを使用できる/すべきであるのに、なぜvarcharデータ型をサポートし続けるのですか？

nvarcharsはvarcharsの「2倍」であるとよく言われることを知っているので、varcarを保持するための1つの論点として、ストレージスペースの使用が考えられます。

ただし、今日のユーザーは、ストレージスペースを節約したい場合、デフォルトのUTF-16ではなくUTF-8としてデータを保存するようにnvarcharを定義できます。これにより、主に望ましい場合は8ビットエンコーディングが可能になりますが、DBに挿入される2〜8バイトのまれな文字が何も破損しないことが保証されます。

何か不足していますか？過去15〜20年でこれが変わっていない理由はありますか？

1. varcharの作業は、いくつかの照合問題の影響を受ける多くの西ヨーロッパ言語（ノルウェー語、デンマーク語、ドイツ語、フランス語、オランダ語など）でも十分です

2. SO varchar vs nvarchar performanceでこれを参照してくださいnvarcharはパフォーマンスに深刻な影響を与えます

3. これは、日付MDYとDMYの処理に比べて簡単です。

標準と互換性に対処する回答に加えて、パフォーマンスにも留意する必要があります。ディスク容量は安価なものとして容易に受け入れられますが、DBA /開発者はクエリのパフォーマンスがテーブルの行/ページサイズに直接関係することがあるという事実をしばしば無視します。（不要な場合）NVARCHARではなく使用するとVARCHAR、文字フィールドの行サイズが事実上2倍になります。たとえば、50または50個の長さのフィールドが5つまたは10個ある場合、行ごとに500バイトを追加する可能性があります。幅の広いテーブルがある場合、各行が複数のページにプッシュされ、パフォーマンスに悪影響を及ぼす可能性があります。

多くの組織には、シングルバイト文字を想定したアプリケーション、インターフェイス、プラットフォーム、およびツールの大規模なインストールベースがまだあります。データベースが孤立して存在することはめったにありません。データベースはITエコシステムの一部です。数千のコンポーネントと1バイト文字に依存する数百万行のコードがある場合、Unicodeに切り替えるのに必要な時間とお金を投資する正当な理由が必要になります。その規模での変更は、完了するまでに数年かかる場合があります。一部の地域では、Unicodeはまだ比較的新しく、まれであるか、完全にサポートされていません。

VARCHARとNVARCHARは両方ともISO標準SQLの一部です。SQL ServerでのVARCHARサポートの削除または廃止は、互換性と移植性の後退になります。

また、今日のユーザーは、ストレージスペースを節約したい場合、デフォルトのUTF-16ではなくUTF-8としてデータを保存するようにnvarcharを定義できます。

これはまさに、ほとんどのオープンソースデータベースが行うことですVARCHAR。

• MySQLは「照合」を提供utf8しucs2ます。
• SQLiteでは、UTF-8（デフォルト）とUTF-16を選択できます。
• PostgreSQLはUTF-8をサポートします（UTF-16はサポートしません）。

2つの別個の文字列タイプを持つ必要はありません。

Microsoftは、8ビット文字列はレガシーエンコーディング用であり、Unicode = UTF-16であるという見方では奇妙です。これはおそらく、Windows API自体の処理charとwchar_tその方法に関連しています。

私たちの中には、ユニコード機能を必要としない最先端のハードウェアよりも軽量で小型のアプリケーションを構築するためです。後で変更する必要があるかもしれませんが、今のところは必要ありません。NVARCHARの下にある必要があるスペースの1/2を占める文字列が好きです。