2012-03-09 9 views
1

データベース内の特定のIDに関連付けられたすべてのデータをコピーするストアドプロシージャを作成するタスクが与えられました。このデータは、数十の表にまたがります。各テーブルには、数十の一致する行があります。PK FK関係の後、複数のテーブルから行を再帰的にコピー

例:

テーブルアカウント
PK =アカウントID

表AccountSettings
FK =アカウントID

表ユーザー
PK =ユーザID
FK =アカウントID

表UserContent
PK = UserContentID
FK =ユーザーID

私はコピーが新しいアカウントIDとUserContentIDを持つことになります(ほぼすべてのテーブルを横断します)が、同じユーザーIDを持っていますアカウントIDに関連付けられているすべてのコピーを作成したいです。新しいデータをそれぞれのテーブルに格納する必要があります。 :)楽しいですか?

上記は単なるサンプルですが、私は50または60のテーブルのようなものでこれを行います。 私はCTEを使って研究しましたが、まだ少し曇っています。それが最良の方法であると判明する可能性があります。私のSQLのスキルは......まあ私はこれまでに約40ログした時間を費やして作業しています:)

見た目についてのアドバイスや指示があれば幸いです。さらに、私はC#でこれを行うことに反対することはできません。

ご協力いただきありがとうございます。個別に各テーブルを処理し、非常に長いPROCを書く:

+0

あなたの例では、1つのアカウントは0-nユーザーを持つことができますが、** 1ユーザーは0-1アカウントのみを持つことができます** => 2番目のアカウントに対して同じユーザーIDを持つことはできませんもちろん最初のアカウントへのユーザーの接続を削除したくない) – Aprillion

+0

うわー。私はこのようにはしません。 CTEは100回だけ再発するため、これを超えることができます。なぜ新しい行が追加されなくなるまで、一時テーブル内のテーブルの外部キーに基づいて一時テーブルに追加を続けるのはなぜですか? – saarp

+0

@saarp:なぜCTEは100回だけ繰り返すのですか?それは馬鹿げた前提です。 –

答えて

3

これを解決する最も簡単な方法は、強引な方法です。これはエラーが発生しやすく、維持しがたいものです。しかし、特に整合性のある状態になるようにデータベースやデータベースのメタデータに依存しないという利点があります。

あなたがメタデータに基づいて動作する何かをしたい場合は、物事はより興味深いものです。

  1. 関連するすべてのテーブルをプログラムで特定する必要があります。
  2. すべての50または60のinsertステートメントを生成する必要があります。
  3. アカウントテーブルから1,2ステップ以上離れたテーブルの生成IDをキャプチャする必要があります。さらにコピーされたレコードの外部キー。

私は過去にこの問題を見てきましたが、水密アルゴリズムを提供することはできませんが、私はあなたに一般的なヒューリスティックを与えることができます。言い換えれば、これは私がそれにアプローチする方法です。

  1. MS Entity Frameworkの後のバージョン(C#を使用していると言いました)を使用して、アカウントテーブルとすべての関連テーブルのモデルを作成します。
  2. これを確認してください。データベースが多くの場合、アプリケーションが想定している関係の中には、何らかの理由でデータベースに実際の外部キー関係が設定されていないものがあります。とにかくそれらをあなたのモデルで作成してください。
  3. C#でAccountオブジェクトを受け取り、関連するすべてのテーブルをトラバースできる小さな再帰ルーチンを作成します。いくつかのAccountインスタンスを選択し、テーブル名とキー情報をファイルにダンプします。完全性と妥当性を確認してください。
  4. 良いモデルと優れたアルゴリズムがあれば、すべての問題を解決することができたら、コードを解読してみましょう。あなたは、アカウントを読み込み、それを参照するすべてのレコードを再帰的に複製できる、より複雑なアルゴリズムを書く必要があります。これを行うには、おそらくリフレクションが必要ですが、それほど難しいことではありません。必要なメタデータはどこかにあります。
  5. コードをテストします。デバッグには十分な時間が必要です。
  6. 手順3で、最初のアルゴリズムを使用して、完全性と正確性の結果を比較します。

EFアプローチの利点:データベースが変更されるとモデルも変更され、コードがメタデータベースの場合は適応することができます。

欠点:実際には同じだが異なるタイプのフィールドや、適切にモデル化されていない複雑な3方向関係などの現象がある場合、または解析する必要のある埋め込みCSVリストこれは動作しません。あなたのデータベースが適切な形でよくモデル化されている場合にのみ機能します。さもなければ、あなたは無理な力に頼る必要があります。

+0

ありがとうございます。私は長いことすべてを書いてしまった。 1800行ほどかなり大きいですが、それはとてもうまく動作します。それを最新に保つことは苦痛になるでしょう。あなたの考えをありがとう。 – user1260249

+0

+1良いアドバイス。私は自分のソリューションでEFを使用してしまったので、当初期待していたよりもはるかに簡単だったので、私は間違いなくそれを使用することをお勧めします。さらに、維持したり、スケールアップしたりする方がはるかに簡単です。 – tfrascaroli

+0

@tfrascaroli名声をいただきありがとうございます!私のアドバイスが役立ってうれしいです! –