c# - プロジェクトをSQLServerに変換し、設計上の考えはありますか？

Question

現在、私はAccessで記述された醜いビジネスアプリケーションに座っています。このアプリケーションは、隔日でスプレッドシートを取得し、それをMDBにインポートします。私は現在、これを含む主要なプロジェクトをSQL Serverと.net、特にc＃に変換しています。

この情報を格納するために、Master_Prodテーブルの親であるIDキーProdIDで結合されたMaster_ProdとMaster_Sheetを呼び出す2つのテーブル（ここではエイリアス名）があります。履歴を保存するためのテーブルがさらに2つあります。History_ProdとHistory_Sheetです。Master_Prodから拡張されたテーブルは他にもありますが、説明のためにこれを2つのテーブルに制限しています。

これはAccessで記述されているため、このファイルを処理するためのサブルーチンには、手動でコーディングされたトリガーが散らばっていて、これまでも常に苦労してきた履歴を処理します。これがデータベースサーバーに移行したことをうれしく思う理由の1つです。 RADツールではなく。履歴追跡を処理するためのトリガーを作成しています。

私の計画は、スプレッドシートをモデル化するオブジェクトを作成し、データを解析して、サーバーにデータを送信する前にクライアント側でLINQを使用してチェックを行うことです...基本的に、シート内のデータを一致するものと比較する必要がありますレコード（存在しない場合は、新しい）。いずれかのフィールドが変更されている場合は、更新を送信します。

もともと、この形式のスプレッドシートがすでにあるので、このプロシージャをIEnumerableリストを受け入れるある種のCLRアセンブリに入れたいと思っていましたが、最近、これがかなり重要なデータベースサーバーとペアになることを知りました。行き詰まりを非常に心配しています。

これは、CLRストアドプロシージャを使用する価値がありますか？データが入力される他のエントリポイントがあり、渡されたオブジェクトを指定してそれらを処理するプロシージャを構築できれば、潜在的なデータベースパフォーマンスを犠牲にして、アプリケーションから多くのビジネスルールを取り除くことができます。

基本的に、更新チェックをクライアントから取り除き、データベースに配置して、履歴トリガーを起動できるようにテーブルを更新する必要があるかどうかをデータシステムが管理できるようにします。

同じ方向に沿ってこれを実装するためのより良い方法についての考えはありますか？

Answer 1

SSISを使用します。Excel Sourceを使用してスプレッドシートを読み取り、ルックアップトランスフォーメーションを使用して新しいアイテムを検出し、最後にSQLServerの宛先を使用して不足しているアイテムのストリームをSQLに挿入します。

SSISは、linqがどれほど楽しいものであっても、ゼロから何かを書くというこの種の仕事にはるかに適しています。SSISパッケージは、ソースが忘れられている一部のdllよりも、デバッグ、保守、およびリファクタリングが簡単です。さらに、高スループットのデータフロー用にSSISがバッファを管理する際の改良点に匹敵することはできません。

Answer 2

もともと、この形式のスプレッドシートがすでにあるので、このプロシージャをIEnumerableリストを受け入れるある種のCLRアセンブリに入れたいと思っていましたが、最近、これがかなり重要なデータベースサーバーとペアになることを知りました。行き詰まりを非常に心配しています。

動作しません。C＃で記述されたCLRプロシージャへの入力は、通常のSQLセマンティクスに従う必要があります。変更できるのは内部設定だけです。クライアントとの通信はすべてSQLで行う必要があります。これは、実行/メソッド呼び出しを意味します。列挙可能なオブジェクトを直接渡す方法はありません。

Answer 3

私の計画は、スプレッドシートをモデル化するオブジェクトを作成し、データを解析して、サーバーにデータを送信する前にクライアント側でLINQを使用してチェックを行うことです...基本的に、シート内のデータを一致するものと比較する必要がありますレコード（存在しない場合は、新しい）。いずれかのフィールドが変更されている場合は、更新を送信します。

おそらく、アプローチの「中心性」、つまりデータ中心またはオブジェクト中心を選択する必要があります。

私はおそらく最初にデータを適切にモデル化するでしょう。これは、リレーショナルデータベース（またはリレーショナルデータベースで表される正規化されていないモデルでさえ）がクライアントツール/ライブラリアプリケーションよりも長持ちすることが多いためです。私はおそらく、通常の形式でモデル化を試み始め、この時期にも言及したように、監査/履歴を維持するためのトリガーについて考えます。

次に、通常、入ってくるデータについて考えます（実際には、オブジェクトモデルやエンティティではありません）。そこで、入力の形式とセマンティクスに焦点を当て、データモデルに不適合があるかどうかを確認します。おそらく、データモデルに誤った仮定があった可能性があります。はい、スプレッドシートは悪名高い入力ソースですが、スプレッドシートを検証するオブジェクトモデルを作成することは考えていません。Remusと同様に、SSISを使用して、おそらくステージングテーブルに取り込み、さらに検証を行ってから、T-SQLを使用して本番テーブルに適用します。

次に、私の優れたソリッドデータモデルに基づくオブジェクトモデルを備えたクライアントツールについて考えます。

あるいは、オブジェクトアプローチは、スプレッドシートをモデル化することを意味しますが、データベースに永続化する必要があるオブジェクトモデルも意味します。おそらく、2つのオブジェクトモデル（スプレッドシートと完全なビジネスドメイン）とデータベースモデル（ストレージの永続性）があります。スプレッドシートオブジェクトモデルは、システムのビジネスドメインオブジェクトモデルほど完全ではありません。

このような使い捨ての外部オブジェクトモデルを持っていた例を考えることができます。入力ファイルを記述したレイアウトファイルである「マスターファイル」を読み取ります。このオブジェクトモデルにより、プログラムはSSISパッケージ（およびBCPおよびSQLスクリプト）を構築して、これらのファイルに対して他の操作をインポート/エクスポート/実行することができました。事実上、これは使い捨てのオブジェクトモデルであり、行内のデータや親行と子行の間のナビゲーションなどの実際のモデルとしては使用されませんでしたが、単に内部目的の内部表現である必要はありませんでした。 「ドメイン」エンティティに対応します。