SQL Server 2005で数値と文字列の両方の値を含むことができるフィールドをモデル化する方法はありますか。

Question

私は新しいデータベーステーブルを作成する必要があります。
論理的には、ID、name、および"value"が含まれています。
その値フィールドは、数値でも文字列でも構いません。

フィールドをvarcharにしたいとは思っていません。WHERE value > 0.5などのフィルタを使用してクエリできます。

SQL Server 2005でこの概念をモデル化する最も良い方法は何ですか？

EDIT： 私はここに（数値の1、非数値の1）を複数のフィールドを作成するには反対しないんだけど、彼らはすべて実際には同じ概念だから、私はそれがだっ確認されませんでしたいい案。
私は別々のフィールドを作成してから、ビューを1つの論理カラムにまとめることができると思います。

これに関する意見はありますか？

私が達成したいのは、とてもシンプルです...通常、このデータはグリッド型の表示では盲目的に表示されます。
また、そのグリッド内の数値をフィルタリングすることもできます。この表は数千万のレコードに収まるので、私はパフォーマンスを照会してコーナーに自分自身を描きたくはありません。
パフォーマンスのクエリが私の主な関心事です。

Answer 1

データを混合する際の問題は、Sql 2005がテキストデータをどのようにソートするかにあります。それは「自然な」ものではありません。

あなたがvarchar型のフィールドを持っているとあなたが行う場合は、次の

where value > '20.5' 

値のように

（「20.5」の後に来る文字ベースのソート「5」のように）「5」あなたの結果になります

別々の列で保管する方が良いでしょう。私はその後、ソートのシングルにそれらを合体ビューを持って、別のフィールドを作成することができると思い

select [ID], [Name], Coalesce([value_str], [value_num]) 
from [tablename] 

Answer 2

数値と文字列の値を同じ列に格納する場合は、その列をクエリフィルタとして使用するときに大量のキャストと変換を避けることはできません。

Answer 3

クエリをサポートするには、数値を格納するnumvalueと文字を格納するtextvalueの2つの列を使用するのがよい方法です。それらはヌル可能でなければならないか、少なくとも値を表さないいくつかのデフォルトを持っていなければなりません。アプリケーションは、その値を格納する列と値なしで残す列を決定できます。

Answer 4

2列。

Answer 5

varchar型とint型の両方の列を持つことはできません。値をvarcharとして保存し、クエリ中にintにキャストすることができます。しかし、この方法では、値に任意の文字が含まれていると例外が発生する可能性があります。あなたは何を達成しようとしていますか？

Answer 6

文字列を保持できるようにするには、列varcharなどを作成する必要があると思います。

代わりに、1つの値の列の代わりに2つまたは3つの列を持つことができます。 3つの列、value_type（ "number"と "string"の間の列挙型）、number_value、string_valueがあるかもしれません。その後、私はあなたがあなたのデータ型としてVARCHARまたはNVARCHARを使用して周りを取得することができるようになるだろうとは思わない、そのクエリが

WHERE value_type = 'number' AND number_value > 0.5 

Answer 7

であることを再構築することができます。記述しているような混合データの場合、フィールドをdbから抜き出し、データ型に基づいて適切なCASTまたはCONVERTを実行するときに値をテストする必要があります。

Answer 8

：あなたがそれらをあなたの結果にマージが必要な場合

利用合体は、1列にそれらをマージします論理列。それに関する意見はありますか？

データソースによって異なります。あなたが何らかの自由形式の方法でユーザー（または他のシステム）からデータを取得していて、そのデータのタイプを本当に気にしていない場合、それを格納する最も良い方法は最も一般的な方法です（varcharなど） 。着信データがより構造化されていて、その構造を気にしている場合は、別のフィールドを使用してその構造をデータベースに保持する方が理にかなっています。

SELECTの観点からは、それは問題ではありません。あなたはそれをどちらかの方法で保存し、同じスキーマとして読むことができます。フィルターに入ると（言及したように）、少しばかり毛深くなりますが、それでも簡単に実行できます。ただし、このデータを更新する必要があるかどうかについて言及していない場合は、データの検証を実施する必要がある場合は言及しません。

そのサウンドから、格納される値の「タイプ」に基づいて、さまざまなタイプの検索を行う必要があります。このように、Typeフィールドを追加することで、あらゆるフィルタを気にかけたい値のタイプにすばやく限定できるようになります。タイプによって、より論理的なアプリケーションスコープであるタイプを意味します。格納されている実際のデータ型ではありません。

UPDATEを簡単にサポートする必要がある場合や、SELECTとフィルタリングがすべて必要な場合は、複数のフィールド（またはテーブルが完全に異なるデータセットの場合はテーブル）を使用する必要がある場合は、Typeカラムのフィールドを1つ使用することをお勧めします。

Answer 9

"string"列NOT NULLとNULL値を許可する "numeric"列の2つの列、1つの "文字列"と1つの "数値"（それらの任意のものが適切です）を使用することを検討することができます。値を挿入するときは、常にその型の「文字列」列を代入します。ただし、値が数値の場合は、数値列に格納します。今では、型のインジケータが組み込まれています（数値型の列に数値が入力されていれば文字列ではない場合）、常に「文字列」列から表示する値を引き出すことができます。計算の「数値」値、または必要に応じて適切な数値ソート/比較を行います。値の型を示す3番目の列を追加することもできますが、この方法ではその必要性が排除されます。一連のINSERTトリガーとUPDATEトリガーを使用して数値と文字列の値を維持することも考えられます。