2017-05-19 11 views
0

私は表、フィールドを持つデータ辞書であるDD、(例えば):SQL Serverでは、別のフィールドの内容に基づいてフィールドの型を変換できますか?

ColumnID (longint PK), ColumnName (varchar), Datatype (varchar) 

私は別のテーブル、Iは、フォーム内のレコードのセットを有するV:

ColumnID (longint FK), ColumnValue (varchar) 

Vのレコードセットを別のテーブルに変換できるようにしたい場合、各フィールドはの値(DD.Datatype)に基づいて変換され、宛先テーブルは(たとえば)

ColumnID (longint FK), ColumnValue (datetime) 

は私が

CONVERT(value of DD.Datatype, V.ColumnValue) 

ような何かをできるようにする必要がありISTM、これを実行することができるように、誰もが私にこの構文がどうなるかさえ可能、そうであればあるかどうかのいずれかの手がかりを与えることはできますか?私のgoogle-fuは関連するものを見つけるのに不十分だと証明しました

+1

すべての*特定の*クエリは、常に固定の "形状"を持つ結果セットを生成します - カラムの数、名前、および*タイプ*。確かにここであなたの質問に暗示されているように見えるものはありません - 結果セットは、潜在的に、それぞれの行*が異なるタイプの値を含む列を持っています。 –

+0

はい、私はそれを手に入れます。私がやってみたいのは、親テーブルと子テーブルのレコードセットの正規化されていないビューを作成することです。 元の名前を使用すると、親テーブルに1レコード、*親レコードの属性である* V *レコードがあります。私の出力は親レコードの子であった* V *の各レコードからparent *と* 1フィールドのフィールドを含むテーブル* Results *になります – khafka

+0

おそらくソースデータと望ましい出力に関する詳細を提供できるお手伝いします。ここから始めましょう。 http://spaghettidba.com/2015/04/24/how-to-post-a-t-sql-question-on-a-public-forum/ –

答えて

1

あなたは動的SQLでこのようなことを行うことができます。データ型が結果セット内のCOLUMNのプロパティであり、結果セット内の各セルではないという制限を認識している限り、したがって、指定された列のすべての行は、同じデータ型を持たなければなりません。

0

CONVERT(value of DD.Datatype, V.ColumnValue)のようなSQLを実行する唯一の方法は、動的SQLです。基本的には、ストアドプロシージャを使用してクエリを効率的に保つ必要があるなど、独自の問題があります。

また、1つのクエリでデータ型のメタデータをフェッチし、アプリケーションで新しいクエリを作成してからデータベースを再度照会することもできます。あなたは、SQL Serverの2012+を使用している、あなたもTRY_CAST()TRY_CONVERT()を使用してみてください、とのようなクエリを書いたと仮定すると:

SELECT TRY_CAST(value as VARCHAR(2)) FieldName 
FROM table 
WHERE datatype = 'VARCHAR' AND datalength = 2 

しかし、再び、あなたは有効なタイプが何であるかを知っているんです。動的SQLを使用せずにSQLで動的に決定することはできません。変数やパラメータは、オブジェクト名や型名には使用できません。しかし、あなたが何をしても、の結果セットの特定の列のすべてのデータは、同じデータ型のである必要があることを覚えておく必要があります。

ほとんどのEntity-Attribute-Value tablesは、データ型がRDBMSではなくアプリケーションによって決定されることを受け入れることによって、強い型指定がもたらすデータの完全性を犠牲にしています。 EAVではケーキ(固定スキーマのないデータを保存する)とそれを食べることはできません(強くデータを入力するDBを堪能し、アプリケーションの文字列を型キャストする必要はありません)。

EAVはデータ正規化をかなりひどく破ります。それは第一正規形を破る。最も基本的なルールであり、これは結果の単なる1つです。 EAVテーブルは、データを厄介なものから非常に困難なものにクエリすることになります.RDBMSはリレーショナルモデルの周りに構築されているため、パフォーマンスを犠牲にすることはほとんどありません。

EAVテーブルを使用するべきではありません。ユーザー定義フィールドでは比較的優れています。しかし、それは常に彼らがクエリと管理に吸うつもりだという意味です。それは単なるトレードオフです。あなたはファーストノーマルフォームを破った。クエリとパフォーマンスは、その選択の結果に苦しんでいます。

すべてのようなデータをこのように保存したい場合は、データをXMLまたはJSON(SQL Server 2016)のブロブとして保存する必要があります。 SQL RDBMSではなくMongoDBやCassandraのようなNoSQLデータストア。

+0

おかげさまで@Bacon Bits子テーブルにレコードのセットではなく、XMLまたはJSONとしてデータを格納する方がよいでしょう。これは、XML/JSONアプローチの明確な利点が分かるからです。 クエリのパフォーマンスは問題ではないかもしれませんが、それは私が慎重に考えなければならないことです。ある意味では、クライアントアプリケーションに役立つように特定の変換が必要な大きなデータダンプを構築しています設計;他方では、データを直接使用可能にすることは、ほとんどの場合、明らかに良好である – khafka

関連する問題