3

MS Access データベースから情報を取得する VB.NET Windows アプリケーションがあります。アプリケーションの主な役割は、さまざまな形式の Excel ファイルから情報を抽出し、ファイル レイアウトを標準化し、それを csv ファイルに書き出すことです。アプリケーションは、キーと相互参照ファイルのソースとして MS Access を使用します。

Windows アプリは、データベース間のユーザー操作の多くに型指定されたデータセットを使用します。標準化は、各クライアント マシンで行われます。アプリケーションではありません...どのように私はこれを言うことができます...速い:-)。

質問: DB とアプリケーションを SQL Server 2005 に移行する最善の方法は何ですか。SSIS パッケージで標準化のためのコードを記述するのは良い考えだと思います。

この移行の適切な方法は何ですか?

このアプリケーションは、毎週 250 個の Excel ファイルから、毎月約 800 個のファイルから、ファイルあたり平均約 5000 行のデータを取得します。標準化され、3 つの異なる標準形式に出力される 13 の異なるファイル形式があります。申請には25分かかります。対象のデータの実行に応じて、実行に 40 分かかります。アプリケーションの 95% は標準化プロセスです。ユーザーが行うことは、いくつかのパラメーターを選択して実行を開始することだけです。

4

5 に答える 5

2

Microsoft は、Access データベースを SQL Server に移行するための無料ツールを提供しています。アップグレードしたら、接続文字列を SQL Server を指すように変更できるはずです。

于 2008-11-01T01:26:50.830 に答える
1

プロファイラーを使用してアプリを実行し、Access DB が実際にアプリの速度を低下させている原因であり、それ以外の原因ではないことを確認したい場合があります。それを SQL サーバーに変換するためにすべての作業を行い、何も表示されないのは残念です。

于 2008-11-01T01:28:04.713 に答える
1

Access のアップサイジング ウィザードを開始点として使用できます。

フロント エンドを変更せずに、バックエンドを Access のリンク テーブルを持つ SQL Server に変更できる場合があります。次に、フロント エンドを変更して、自由に SQL Server に直接接続できます。

Access に非常に大きな打撃を与えていない限り、それがボトルネックであるとは思えません。

Excel ファイルを読み取る限り、SSIS はそれを実行できますが、VB.NET コードにある程度処理するスマート ロジックが多数ある場合、現在 VB.NET で使用しているメカニズムほど信頼性が高くない可能性があります。入力ファイルの変動

データを CSV に書き出す限り、SSIS は問題ありません。SSIS は非常に優れたパフォーマンスを発揮することがわかりました。

ワークフローと、構成をプルするプログラムと比較して、ユーザーがデータベースと対話する量について詳細を提供できれば、アーキテクチャを支援するのが簡単になる可能性があります。

SSIS はオンザフライで非常に構成可能 (実行中にパッケージ自体が多少構成されます) であり、多くの場合、さまざまな Excel ファイルを読み取って CSV に変換するようにプログラムできますが、その場で手動で構成することはできません。 -コード化されたシステム。また、SSIS オブジェクト モデルを使用してプログラムでパッケージを生成し、実行することもできます。これには、パッケージ自体を構成する制限の一部はありませんが、オブジェクト モデルはかなり複雑です。

于 2008-11-01T01:32:05.030 に答える
0

したがって、クライアントごとに毎週: 25 分間で 250 ファイル = 10 ファイル/分またはファイルあたり 6 秒。

毎月、クライアントごと: 40 分で 800 ファイル = 20 ファイル/分またはファイルあたり 3 秒。

私の期待は1秒未満です。ファイルごと (5000 行) のラウンド トリップには以下が含ま
れます。xls を mdb にインポートまたは添付し
ます。 b. Access SQL による変換
c. csv にエクスポート

頭に浮かぶ唯一の説明は、おそらく .NET アプリが一度に行を読み取り、変換し、保存しているということです。もしかしてそうですか？

SSIS に変換すると、SSIS 自体が ETL を処理 (および保存) する必要があるため、.NET アプリが廃止される可能性があります。つまり、基本的にソフトウェアを書き直すことになります。ただし、Access よりも SSIS の方が適切なリソースがある場合があります。しかし、それはやり過ぎのように思えます。しかし、VBA ではなく .NET もやり過ぎかもしれません。VBAでの書き換えも仕事です。最小の労力は、ETL 全体を実行 (および保存) できるかどうかを確認することだと思います.

少なくとも基本的なユースケースのプロトタイプを作成し、現在どこに時間が費やされているかをすぐに見つけられるかどうかを調べることができると思います (以前の回答で示唆されているように)。問題の間違った部分。それらの領域を少し広げていただければ、さらにご案内できると思います。しかし、Access は、(IMHO) SQL Server + SSIS + .NET よりも低い TCO で、この種のものに非常に適しています。

言うまでもなく、csv ファイルが真のエンドポイントであり、決定に影響を与える可能性がある場合は驚くでしょう。Excel のデータは、実際にはさらに先にあるのではないでしょうか。

最後に、25 分から 40 分のプロセスが無人であり、昼休みを超えて実行され、基本的には問題なく動作する可能性があるというのは、どの程度好ましくないのでしょうか?

ノート：

週あたり    

エクセルファイル 250
分 25
分/ファイル 0.1
秒/ファイル 6


毎月   

エクセルファイル 800
分 40
分/ファイル 0.05
秒/ファイル 3
于 2008-11-01T03:37:37.087 に答える
0

範囲が明確であることを確認します。

  1. .NET プログラムを使用して
  2. 次のことを可能にする Access データベース フロントエンドを駆動します。
  3. 多数の Excel スプレッドシートからデータを抽出し、
  4. データを適切に処理し、
  5. 結果を CSV ファイルに保存します。

どのような種類のボリュームについて話しているのですか? クライアントの数、クライアントごとのスプレッドシートの数、スプレッドシートごとの行数 (単一のスプレッドシートの場合、最大で 32767 になると思いますよね? そして、どれくらいの時間について話しているのでしょうか?

可動部分が多いようです。そして通常、Access は (VBA を使用して) この種のことを単独で実行するための非常に優れたツールです。

適切に設計された Access データベースのフロントエンド Excel が VBA を使用してプロセス全体を完了するための主要な時間シンクを提供するのに十分な量ではないようです。代わりに、各クライアントに (Access の代わりに) SQL Server をインストールして操作する場合、管理と運用のオーバーヘッドが増加しないことに驚かれることでしょう。

于 2008-11-01T01:40:03.173 に答える