マルチテナントSQLServerデータベースの上に配置されたSoftwareasa Service（SaaS）Webアプリケーションを維持しています。システムには約200のテーブルがあり、これは100列をわずかに超える最大のテーブルであり、最終的にデータベースのサイズは約10ギガバイトでした。データを入力してレポートを実行するたびに、約25のクライアント企業がアプリケーションを使用しています。
シングルインスタンスアーキテクチャは非常に効果的に機能しています。毎月すべてのクライアントにリリースされる新機能を設計および開発することができます。各クライアントエクスペリエンスは、フィーチャートグル、データディクショナリのカスタマイズ、CSSスキニングなどを使用して構成できます。
私たちの典型的なクライアントは、いくつかの支店、1つの本社、そして時には独自の社内ITソフトウェア開発チームを持つ企業です。
現在直面している問題は、マルチテナントデータベースに現在保存されているデータに基づいて、レポート、データウェアハウジング、ダッシュボードを開発するために、いくつかのクライアントが独自の内部プロジェクトに取り組んでいることです。これらのプロジェクトの数と洗練度は時間の経過とともに増加する可能性が高いと考えており、効果的に対応したいと考えています。
現在、クライアントがテーブルからレコードの完全なダウンロードを取得するために呼び出すことができるセキュリティで保護されたXMLWebサービスを公開する「ライト」ソリューションがあります。それらはテーブルを指定し、それを固定数の列を返す専用のストアドプロシージャにマップします。現在、クライアントは、管理しているローカルSQLデータベースに一晩で約20個のテーブルをプルしています。一部のクライアントは、これらのテーブルのいくつかに数万のレコードを持っています。
この「ライト」アプローチにはいくつかの欠点があります。1）各クライアントは独自のデータプルメカニズムを開発および維持し、すべてのロギング、エラー処理などを処理する必要があります。2）データベーススキーマは絶えず拡張および変更されています。呼び出しているストアドプロシージャの列数は固定されていますが、既存の列を展開すると（たとえば、varchar（50）をvarchar（100）に変換する）、ローカルの列サイズを突然超えたため、プルが失敗することがあります。データベース。3）クライアントごとに構築された何百もの異なるストアドプロシージャと、それらの特定のダウンロードの期待値を蓄積し始めています。これは管理の面倒です。4）より多くのデータを求めるクライアントの要求に対応するのに苦労しています。「シェル」スキーマ（つまり、データが含まれていないデータベースのコピー）を提供し、プルする必要のあるテーブルを選択するように依頼します。
長い質問で申し訳ありませんが、私が探しているのは、他のチームが成功を収めているこの問題へのアプローチです。すべてのデータを最も簡単に使用できる方法で安全に公開したいと考えていますが、データ交換のネゴシエーションやスキーマ変更後のクリーンアップという絶え間ないプロセスに巻き込まれることはありません。
何があなたのために働いたのですか？
ありがとう、
マイケル