Excelデータベーステーブルにアップロード

Question

データウェアハウス（DW）にテーブルを設定するためにXLSスプレッドシートをアップロードできる最適なソリューションを探しています。

ユーザーは大量のビジネスオブジェクト（BO）ユーザーで、BOを使用するとXLSにエクスポートできます。 DWにロードする必要のあるスプレッドシートにデータがある場合、XLSのデータをDWのdbにアップロードするプロセスが必要です。その結果、私たちが本当に必要とするのはプログラマティックな自動フィードだと思うと、これらの「インターフェース」の多くが完成します。 Excelをシステム間フィードのデータソースとして使用すると、私のやり方では、私にとっては悪い考えのように思えます。

質問＃1：あなたが同意するかどうか、なぜ、なぜ、なぜそうではないかを見たいと思います。

OK、その潮に対して泳いでいるわけではないので、今私はXLSのアップロードが私たちのために残っていると考えています。今私は最高のソリューションを見つける必要があります。まず、私たちが何をしているのか、私が気に入らないものについて説明します：

Webページを介して、空のXLSファイル（行なし）に定義された列のセットを提供します。各ファイルは、異なるターゲットdestテーブルを更新するために使用されます。各スプレッドシートには「アップロード」ボタンがあります。 [アップロード]ボタンを押すと、スプレッドシート内のマクロがCSVファイルにシリアル化され、サーバーフォルダにデータがFTPされます。定期的に、スケジューラは、CSVファイルを入力として使用するInformatica ETLジョブを起動し、カスタムXLS固有のステージングテーブルにデータをロードし、レコードが編集を適切なターゲットテーブルに渡します。エラーが発生すると、エラー・テーブルに記録されます。アップロードされたXLSファイルごとに、データはファイルに固有のステージングおよびエラーテーブルに格納されます。私は好きではない、物事のいくつかは、私たちのプロセスについて含ま

は以下のとおりです。

は

1）あまりにもさらされているXLSでマクロコード、例えばパスワードが含まれ、改ざんすることができ、確実に問題があることユーザーは最新のXLSテンプレートを使用しています。 2）ビジネスルールの編集はETLプログラムに置かれます.ETLプログラムはおそらく存在するはずですが、スプレッドシート内のエラーASAPをキャッチしたいので、編集もマクロコードに追加されます。その結果、業務上の編集が重複します。私はこれらのルールを一箇所に集中して集中管理したい。 IMHO、私はXLSにマクロコードを置くと、ストアドプロシージャ（いくつかのものがあります）やWebサービス（MicrosoftがまだXLSマクロから.NET Webサービスを呼び出そうとしていない）を呼び出すという保守上の問題があると思います。 ） 3）すべてのXLSファイルアップロードテンプレートには、固有のステージングテーブルとエラーテーブルがあり、エラーが発生した場合のカスタム画面が表示されます。より一般化された再利用可能なソリューションが必要なようです。

多くのレコードを編集するのは簡単で、Webインターフェイスから個々のレコードを編集するよりも簡単であるため、ユーザーはExcelから好きなようにXLSにデータをエクスポートできます。

はまず、私は、ユーザーが編集のExcelの編集のしやすさを持っているしたいのですが、スプレッドシートに埋め込まれたマクロを含めず：

これは私が考えています一般的な方向です。私は... Excelの互換性を持つFarpointのグリッドで

http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx

を実験...と私はユーザー自分のPCに常駐していXLSファイルを開く機能を可能にするためには非常に簡単であることがわかりましたブラウザで開き、サーバー側の.NET Webコードから読み取ったデータに簡単にアクセスできるようにします。Excelはブラウザではローカルに実行されていませんが、Excelの機能が再現されています。おそらく、クライアントサイドスクリプトの多くが、おそらく自分自身を複製するのに苦労するでしょう。ローカルのスプレッドシートからWebのスプレッドシートにカットアンドペーストすることもできます。最大の問題はコストです。当社は死にそうであり、新しいソフトウェアを購入することはできません。

次に、すべてのスプレッドシートのアップロード処理で共通のコンポーネントを特定し、ジェネリック処理コードを作りたいと思います。たとえば、私は、各スプレッドシートと、おそらくハードコーディングの代わりにデスティネーション列の観点から、列名とデータ型定義を含むそれぞれの形式を定義する表を想像します。このテーブルテンプレート定義に基づいて、このテーブル定義からダウンロードするためのXLSテンプレートを生成することができます。入力したデータが表定義と一致するように、単純な汎用編集を実行することもできます。また、1つの一般的なWebページを使用してデータを表示し、レポートデータ型の不一致エラーを許可し、ユーザーがそれらを修正できるようにします。私はまた、2つの列、サブミッション＃、行番号、名前と値を持つテーブルを使用して、 "ステージング"テーブルにデータを格納するための共通テーブルを定義します。これ以上の「カスタムすべて」は目標ではありません。

次は、ビジネスルールをどこに置くかを決定する必要があります。私の部署は、すべてのデータのロードはInformatica ETLバッチプロセスで行う必要があると確信しているため、ルール/編集は「Informatica」に属しています。私はInformaticaツールでの経験はゼロですが、私は.NETの人です。したがって、これらのルールがどのように実装されているかは不明ですが、特定のレコードを検証するために.NET Webページで使用できるという意味で再利用できないと思われます。ユーザーが一括アップロードを実行していない場合、特定のレコードを編集する機能があり、ETL一括挿入プロセスによって適用された同じ編集を個々の更新プログラムに適用したい場合がありますウェブページを介して単一のレコードにしよう。 1つのWebサービスまたはストアドプロシージャを記述するソリューションが、単一レコードの更新を行うWebページか、一括アップロードの各レコードの何千回も呼び出されるストアドプロシージャである場合は、後者は非効率的と思える。

あなたの考えは大歓迎です。

Answer 1

費用面では、Web上でスプレッドシート機能を再作成するために必要な作業は、Farpointや他のコントロールのコストを上回ります。あなたが1時間に20ドルを出したとしても、2週間以内に有効な製品を完成させることができると思いますか？ ETL機能がExcelに存在することを許可すると、保守の問題について話し合ったときに、変換ルールを維持するための作業量が2倍になっていると思います。メンテナンス可能で堅牢なソリューションを作成するには、柔軟なユーティリティが必要であることを経営陣に納得させる必要があると思います。

ファーポイントは良い選択です。 SpreadsheetGearは、Excelマクロを解釈し、Webサーバー上で実行できる.Netエンジンです。それは非常にExcelインターフェイス機能を持つWinFormsソリューションを作成することができますWin32コントロールがあります。私が最後にチェックしたのは、その製品のWebコントロールがなかったことです。大量のデータを処理するためのExcel機能を提供するという優れた仕事をしています。

幸運。私はあなたが良いソリューションを見つけると思います。なぜなら、あなたはプロと潜在的なすべての解決策をよく理解しているようです。