0

フォーム データを SQL サーバーに保存する必要がある状況がありますが、セットアップする新しいジョブごとに、フィールド名と長さが異なるさまざまなフィールドがあります。例

Job 1:
    Field 1: first_name - varchar(20)
    Field 2: last_name - varchar(30)

Job 2:
    Field 1: first_name - varchar(15)
    Field 2: middle_initial - varchar(1)
    Field 3: last_name - varchar(30)

最初は、問題のフォームに正確に準拠したこのデータを格納するために別のテーブルを設定していました。しかし、このデータの動的な性質に対応するために、非常に多くのテーブル、procs、dts、ssis パッケージが毎回変更されるため、メンテナンスの悪夢につながります。

すべてのデータを xml フィールドに格納する別のソリューションを思いついたので、ほとんどの問題は解決しました。現在はこれと同様に存在します。

<Record>
  <first_name>value</first_name>
  <last_name>value</last_name>
</Record>

次に、このデータをテーブルから引き出すビューを作成します。

SELECT
,  IsNull(data.value('(/Record/first_name)[1]', 'varchar(20)'),'') as first_name
,  IsNull(data.value('(/Record/last_name)[1]', 'varchar(30)'),'') as last_name
FROM FormTable

これは以前よりもはるかに優れていますが、毎回カスタム ビューを作成する必要があることも意味します。フィールドをリストし、そのクエリを作成する何らかのタイプのテーブルを維持したいと思います。

Field Name | Field Type | Field Length
first_name | varchar    | 20
last_name  | varchar    | 30

動的ビューを作成できないと確信しています。機能する可能性のあるオプションの 1 つは、テーブル値関数です。しかし、ここで見落としているものはありますか？この方法でデータを動的に保存できるようにするためのより良いオプションはありますか (CouchDB などの他のデータベースがこれをネイティブに行うことがわかっているため、SQL SERVER から離れることはありません)。

4

1 に答える 1

0

動的SQLまたは一時テーブルを使用できないため、テーブル値関数は機能しないと確信しています（これを行うには、ほぼ確実に使用する必要があります）。

ストアド プロシージャは当然の選択です。必要なすべてのことを実行できますが、問題はもちろん、ストアド プロシージャから SELECT できないことです。

このようなことを行うための一連のオプションについて説明しているこのページを見ていました。彼が言及しているオプションの 1 つは OPENQUERY を使用することです。これは非常に簡単に思えますが、パフォーマンスの問題が発生する可能性があります。

SELECT * FROM OPENQUERY(LOCALSERVER, 'EXEC sp_getformdata')

とにかく、そのリンクをチェックして、追加のアイデアを得ることができます.

于 2009-07-02T18:21:09.797 に答える