0

私はこれに対して頭を悩ませてきましたが、明らかな何かが欠けているだけだと確信していますが...

顧客のデータベースにテーブルがあります。基本的には次のとおりです。 

Item_Set_Key int
Item_1       bit
Notes_1      nvarchar(80)
Item_2       bit
Notes_2      nvarchar(80)
Item_3       bit
Notes_3      nvarchar(80)
...

各レコードには 99 個のアイテムがあり、スキーマを変更することはできません (他の外部の考慮事項が関係します)。

ただし、リモートでユーザーにインテリジェンスに似たものに表示するには、次のように (ビューを介して) UNPIVOT する必要があります。

SELECT i.Item_Set_Key, i.Item_Number, i.Selected, i.Item, i2.Notes, i2.Note
FROM (
SELECT Item_Set_Key, SUBSTRING (Item, 6, 2) AS Item_Number, Selected, Item
    FROM Item_Set
    UNPIVOT (Selected FOR Item IN
        (Item_1, Item_2, Item_3, Item_4, Item_5, ...)
    ) as u
) AS i
LEFT JOIN (
SELECT Item_Set_Key, SUBSTRING (Note, 7, 2) AS Item_Number, Notes
    FROM Item_Set
    UNPIVOT (Notes FOR Note IN
        (Notes_1, Notes_2, Notes_3, Notes_4, Notes_5, ...)
    ) as n
) AS i2 ON i2.Item_Set_Key = i.Item_Set_Key
    AND i2.Item_Number = i.Item_Number

それをグリッドに標準バインドします。ただし、テキストはSETで列に明示的に名前を付ける必要があるため、UpdateCommandを作成する方法については少し途方に暮れていますが、列名はItem列とNote列で動的であり、できます各レコードには 1 つの項目/メモのペアのデータしかないため、すべての列を設定するだけではありません。

アイデア？

4

1 に答える 1

1

元のピボット テーブルのデータベースに変更を戻すために、データ バインディングに依存することはできません。代わりに、各更新を単一の「作業単位」としてキャプチャする必要があります。たとえば、アイテム id=92、値="Tom" です。おそらく以前のアイテム 92 の値は「Joe」でした。ここでの作業単位は、アイテム 92 の値を変更することです。

ユーザーがユーザー インターフェイスを介して変更を加えると、各 UOW をまとめてバッチ処理し、[保存] をクリックする準備ができるまでそれらを保持できます。ユーザーが保存を要求すると、キャプチャされた各 UOW がデータベースに対して「再生」されます。「コマンド」パターンおよび/または Jeremy Miller の記事の一部を検索してください。

別の考えは、スキーマを変更できないと言ったが、実際には変更できるかもしれないということです。ピボットされていない形式の実際のテーブルを作成することを検討してください。次に、現在のテーブルを PIVOT コマンドを使用するビューに置き換えます。実際には、より優れた設計でデータを保存しますが、既存のアプリケーションの場合は元に戻します。ピボットされたデザインにある間に更新を行う必要がない限り、これはうまくいく可能性があります。

最後のオプションは、単純に 2 つの物理テーブルを維持し、複雑なマージ操作を記述してそれらを定期的に同期することです。

于 2009-09-03T00:36:44.727 に答える