3

私が取り組んでいるプロジェクトをどのように処理するかについて、しばらくアドバイスを探していましたが、役に立ちませんでした。私は、現在取り組んでいる「アプリケーション」を改善するための 4 回目のイテレーションをほぼ実行中です。最初の 2 回は Excel、3 回目は Access、そして今は Visual Studio です。分野は製造業です。

基本的な考え方は、大規模なSybaseサーバーから読み取り専用データを取得し、それをフィルタリングして、Accessで毎日（削除クエリと追加クエリを使用して）はるかに小さなテーブルを作成し、その後、さまざまなことを行うというものです. より具体的には、一連のクエリを使用して、複数のテーブルのデータを結合するか、特定の方法 (集計関数) でデータをグループ化し、このデータをテーブルに配置します (DAO.recordset を使用してデータを並べ替えおよび操作し、実行できるようにします)。複数のカスタム アルゴリズム)。このプロセスは、一連の関連するテーブルが作成されるまで、データベース全体で複数回繰り返されます。

多くの場合、1.1 などの値を持つクエリでフィールドを作成し、それをテーブルに追加するときに、アルゴリズムからフィールドに情報を格納できるようにします。そのため、プロセスが続くと、テーブルのフィールド数が変化します。

アプリケーション全体は、共有ドライブ上でリンクされた 4 つの「バックエンド」データベースで構成され、さまざまな出力 (フロントエンド アクセス アプリケーションまたは Excel) が含まれます。

私の質問は、問題を解決するデータ駆動型アプリケーションがどれだけ本質的に機能するかということです。各バックエンド データベースは毎日新しいデータで更新され、それぞれの更新には約 10 秒 (3 つの場合) および 2 分 (1 つの場合) かかります。

プロジェクトの目的。すぐに SQL Server に移行したい/移行中です。フロント エンドは Web アプリケーション (私は基本的な Web 開発を知っており、管理の柔軟性が好きです) になり、Visual Studio は c#/.NET を使用した IDE になります。

これらのアルゴリズムを「データベース内」で実行するか、サーバー要求ごとに一連の C# 関数を使用する必要があります。実際のデータポイントでない限り、データベースにデータを保存することは想定されていません。Accessには、vbaのアルゴリズムからの計算を保持するだけの列がたくさんあります。

実を言うと、私は複数のプロフェッショナルな Access アプリケーションを見てきましたが、(良くも悪くも) 複雑なアプリケーションや、私のアプリケーションに近いアプリケーションを見たことがありません。しかし、一部のプロ用ソフトウェア アプリケーションは、私のものよりも 1000 倍優れていることを知っています。

ですから、お願いしますお願いします。何らかの提案をお願いします。私は完全に独力で、このプロジェクトに正しい方法でアプローチする方法についていくつかのガイダンスが必要です。

4

3 に答える 3

1

あなたが説明するアプリケーションは、「 ETL 」の例のようです-抽出、変換、ロード。

これは、私がプロのプログラマーとして取り組んだ最初のプロジェクトの 1 つであり、明らかに簡単ではありません。このプロセスを支援するために使用できるツールはたくさんあります (Microsoft のものを含む) が、それらは主にデータ ウェアハウスにデータを入力することを目的としています。それにもかかわらず、ウィキペディアの記事を読み、ETL ツールのいくつかを調べてアイデアを得ることができます。

独自の方法をとる場合は、ETL プロセスを自動的に実行する Windows サービスを作成することをお勧めします。何らかのトリガーでインポートを実行すると仮定します-夜間、毎時、製造システムからメッセージが送信されたときなど。このトリガーをポーリングする Windows サービスを記述します。

次に、データを移動したり、アルゴリズムを実行したりするために必要なサービスからデータベースコマンドを実行します。エラー処理とログに注意してください (サービスにはユーザー インターフェイスがないため、システム ログにエラーを書き込み、誰かが注意を払っていることを確認する必要があります)。データベース コードをストアド プロシージャにラップすることを検討してください。これにより、サービスから呼び出しやすくなります。

これはかなり複雑なアプリのようです。コードの品質に注意を払い、単体テストを検討してください (ただし、データベース コードを単体テストするのは困難です)。プロのコーダーでない場合は、Steve McConnell の「Code complete」を購入して、最初から最後まで読んでください。

于 2012-10-14T20:09:53.100 に答える
1

If you are going to sql server or any other full client server DBMS for that matter, the trick (generally) is to do as much on the server as possible.

Depends on how you've written the code really. In general the optimisations for a desktop are the inverse of those for a server.

For instance if you a Find Customer facility.

In a desktop you'd get the entire table and then use say Locate to find the record by name, post/zip code etc. Because effectively your application is both server and client.

In a Client Server set up, you pass customer Name etc to the DBMS, and let it find the customer(s) that matched and pass only those back.

So in your situation forgetting the web application bit, you've got to look at what your application does and say can I write this in sql.

So

If you had 

// get orders 
foreach(Order order in clientOrders)
{
   if (Order.Discount > 0)
   {
      Order.Value = Order.ItemCount * Order.ItemPrice * Order.Discount;
   }
}
// save orders

you'd replace that with a query that did 

Update Orders Set Value = ItemCount * ItemPrice * Discount 
Where ClientID = @ClientID and Discount > 0

Let the server do the work on the server instead of pulling and pushing loads of data into and out of an application.

If I was you though, I'd either do the sql server piece, or I'd do the web server piece, not both at the same time. In terms of client server there's a lot of overlap. Neither one precludes the other, but a lot of times you'll be able to use either to solve the same problem in slightly different ways.

于 2012-10-14T16:19:03.177 に答える
1

詳細が明らかになるにつれて、アプリケーションの一部が Access db ファイルに 15,000 行を格納して、後でそれらのデータに対して計算を実行できるようになっているようです。

ただし、計算を実行するためにこれらのデータを Access に格納する必要があると考える理由は明らかではありません。

理想的には、これらの計算を実行するようにサーバーに依頼するクエリを作成します。サーバーの機能でそれが不可能な場合、またはサーバーに許容できない処理負荷をかけるほど計算量が多い場合でも、計算に使用するためにすべての生データを Access にダウンロードする必要はありません。代わりに、サーバー上のクエリによって設定されたレコードセットを開き、レコードセットの行を移動して計算を実行し、結果のみを Access テーブルに (2 番目のレコードセットを介して) 格納することができます。

Public Sub next_level_outline()
    Dim db As DAO.Database
    Dim rsLocal As DAO.Recordset
    Dim rsServer As DAO.Recordset
    Dim varLastValue As Variant

    Set db = CurrentDb
    Set rsLocal = db.OpenRecordset("AccessTable", dbOpenTable, dbAppendOnly)
    Set rsServer = db.OpenRecordset("ServerQuery", dbOpenSnapshot)
    Do While Not rsServer.EOF
        rsLocal.AddNew
        rsLocal!computed_field = YourAlgorithm(varLastValue)
        rsLocal.Update
        varLastValue = rsServer!indicator_field.value
        rsServer.MoveNext
    Loop
    rsLocal.Close
    Set rsLocal = Nothing
    rsServer.Close
    Set rsServer = Nothing
    Set db = Nothing
End Sub

それは大雑把なアウトラインにすぎません。の性質に大きく依存しYourAlgorithm()ます。コメントから、前の行と関係があると収集したのでvarLastValue、プレースホルダーとして含めました。

アプローチの一部は、選択したファクトリに適用される 15,000 行に 200 万行のソース行をフィルター処理することでした。WHEREの句でそれを行いServerQueryます：

WHERE factory_id = 'foo'

で行の順序が重要な場合YourAlgorithm()は、 にORDER BY句を含めますServerQuery。

この提案の原動力は、Access にデータを冗長に格納しないようにすることです。また、冗長性を完全に排除できない場合は、少なくともその程度を制限してください。

その後、Access ストレージを 4 つではなく 1 つの db ファイルに統合できることがわかります。単一の db ファイルにより、アプリケーションの他の側面が簡素化され、パフォーマンスも向上するはずです。

アプリケーションの進化の次の段階に進む前に、この問題に完全に対処したことを確認する必要があると思います。この課題が ASP.Net で簡単になるとは思えません。

于 2012-10-14T19:27:56.453 に答える