問題タブ [multi-tenant]

複数のクライアント用に設計されたデータベース中心のアプリケーションでは、すべてのクライアントに単一のデータベースを使用する方が「良い」と常に思っていました。つまり、レコードを適切なインデックスとキーに関連付けます。Stack Overflowポッドキャストを聞いていると、JoelがFogBugzがクライアントごとに1つのデータベースを使用していると聞いた（したがって、1000のクライアントがある場合は1000のデータベースがある）。このアーキテクチャを使用する利点は何ですか？

一部のプロジェクトでは、クライアントがすべてのデータに直接アクセスする必要があることを理解しています。このようなアプリケーションでは、各クライアントが独自のデータベースを必要とすることは明らかです。ただし、クライアントがデータベースに直接アクセスする必要がないプロジェクトの場合、クライアントごとに1つのデータベースを使用することに利点はありますか？柔軟性の観点から、テーブルの単一のコピーで単一のデータベースを使用する方がはるかに簡単なようです。新しい機能の追加、レポートの作成、および管理が簡単になります。

Joel（経験豊富な開発者）が彼のソフトウェアは別のアプローチを使用していると言うのを聞くまで、私は「すべてのクライアントに1つのデータベース」の方法にかなり自信を持っていました。

多数のレコードがあるとデータベースの速度が低下すると言われていると聞きましたが、特に適切なインデックスとキーが使用されている場合は、メリットのあるリレーショナルデータベースでその問題が発生することはありません。

どんな入力でも大歓迎です！

複数のエンティティのデータを管理する Web サイトを開発しています。エンティティ間でデータは共有されませんが、同じ顧客が所有している可能性があります。顧客は、単一の「ダッシュボード」からすべてのエンティティを管理したい場合があります。では、すべてに対して 1 つのデータベースを使用する必要がありますか?それとも、データを個別のデータベースに分離しておく必要がありますか? ベストプラクティスはありますか? 持っていることのプラス/マイナスは何ですか:

• サイト全体のデータベース (エンティティには「customerID」があり、データには「entityID」があります)
• 顧客ごとのデータベース（データには「entityID」があります）
• 各エンティティのデータベース (データベースと顧客の関係はデータベースの外にあります)

複数のデータベースを使用すると、パフォーマンスが向上する (行と結合が少なくなる) ように見えますが、最終的にはメンテナンスの悪夢になる可能性があります。

SaaSアプリケーションがさまざまな方法でホストされているのを見てきました。機能とモジュールを複数のデータベースに分割することをお勧めしますか？たとえば、あるDBにUserテーブル、別のDBに機能/アプリ固有のテーブル、別のDBに他の一般的に共有されているテーブルなどを配置しますか？

ASP.NET でマルチテナント Web サイトを構築しており、各顧客が独自のセキュリティ モデルを構成できるようにする必要があります。独自の役割を定義し、ユーザーをそれらの役割に配置できる必要があります。これを行う最善の方法は何ですか？

次のようなコードを持つ page_load イベントの簡単な例がたくさんあります。

しかし、それはコード内のグループと権限をハードコーディングします。ユーザーが構成できるようにするにはどうすればよいですか?

StackOverflow ポッドキャストでは、No . 19で、Joe は、すべてのクライアントに対して 1 つのデータベースではなく、クライアントごとに 1 つのデータベースを持つという Fogcreek の決定について説明しています。それはちょっと私に次のことを考えさせます。

1. 1000 人のユーザーがいると仮定します。
2. 各ユーザーには100 個のクライアントがあります。
3. 各クライアントには1000 個の製品があります。

つまり、1000 x 100 x 1000 = 100,000,000 個の製品がユーザーに関連付けられることになります。ここで、あるユーザーとそのクライアントのすべての製品に対して結合テーブル クエリを実行する場合、この目的のために 1 つのデータベースのみを使用すると、妥当なクエリ時間はどれくらいになるでしょうか?

アップデート

たぶん、私の質問は十分に明確ではありませんでした。上記で説明したように、データセットを使用してあらゆる種類のファンキーなクエリ (最小、最大、グループなど) を実行する必要があると仮定すると、複数のデータベース戦略を使用する方が理にかなっている点まで遅い (またはそうでない) でしょうか。 . 1 DB/クライアント、データベース シャーディングなど

私は、会社のワークフローとプロジェクト管理を容易にすることを目的とした PHP アプリケーションに取り組んでいます。たとえば、 BasecampやGoPlanなどです。

データベースに関して、最善のアプローチが何であるかはわかりません。単一のデータベースを使用してクライアント固有の列を各テーブルに追加する必要がありますか?それとも、新しいクライアントごとにデータベースを作成する必要がありますか? 重要な要素は自動化です。私は、新しいクライアントを作成するのが非常に簡単であることを望んでいます (そして、おそらく自分でサインアップする可能性を開きます)。

考えられる短所 1 つのデータベースを使用して考えることができます。

• 拡張性の欠如
• セキュリティの問題 (そもそもバグがあるべきではありませんが)

これについてどう思いますか？上記の企業がどのソリューションを選択する可能性が最も高いか、何か考えはありますか?

アプリケーションを「1セットのコードと1つのデータベース」から「1セットのコードから複数のデータベース（顧客ごとに1つのデータベース）」に変更します。

元のコードは、VS2005 ASP.NET（VB）と別のDLL内の多くのXSDです。web.configのConnectionStringは、実行時にDLLに格納されているものをオーバーライドします。

ここで、データアダプター/データセット/テーブルを宣言するたびにConnectionStringを変更する必要があります。これは、呼び出しが前回の呼び出しとは異なるデータベースに送信される可能性があるためです。

誰かがこれについて何かヒントを得ましたか？

各 webapp には独自の個別のデータベースがあることに注意してください (ただし、すべてのデータベースは同じデータベース サーバーにあります)。

シナリオは、マルチテナント SaaS アプリケーションを使用しているというものです。顧客ごとに同じアプリケーションをデプロイしています。各顧客は、 と呼ばれるデータベースで作業しますdb_cid。ここcidで、 は顧客 ID、つまり一意の顧客 ID です。

休止状態での作業。

マルチテナント アーキテクチャの Web アプリで URL を検証して、クエリ文字列パラメーターを変更するだけで、ある組織のユーザーが別の組織のデータにアクセスできないようにする最善の方法は何でしょうか。ページの読み込みごとに検証を行いたくありません。アプリは ASP.net 3.5 で構築されています。

「サブサイト」をサポートする必要がある ASP.NET アプリケーションを設計しています。

アイデアは、スーパー管理者がすべてのユーザー、グローバル アプリケーション設定、およびサブサイトを管理することです。各サブサイトには独自の設定 (ローカル管理者、ロゴ、ウェルカム メッセージなど) がいくつかあり、各サブサイトには独自の登録ユーザー リストがあります。

これは、Joomla、SharePoint、DotNetNuke などの CMS を使用して得られるものと非常によく似ています。実際、私はそのようなプラットフォームを使用したくなりますが、他のプロジェクトの要件により、それを行うことができません。

この時点での私の質問は非常に一般的です。

1. ASP.NET 2.0 Membershipを使用して、スーパー管理者を指定し、登録したサブサイトに基づいてユーザーを分類するにはどうすればよいですか?
2. サブサイトをどのように実装しますか (どのパターンを使用する必要があるかなど) ? 他の人がこれをどのように行ったかを説明する記事に特に興味があります。DotNetNuke のような大規模なオープン ソース プロジェクトのソース コードを何日もかけて掘り下げるのではなく、他の人が習得したベスト プラクティスを学びたいと考えています。

私はこれを ASP.NET MVC 1.0 で実装しているので、同様の例が最も役に立ちます。

---

更新: Mike Hadlow がマルチテナンシーを実装した 方法が気に入ったので、彼の作品を出発点として使用することにしました。各テナントが独自の分離されたデータベースを使用している方法については、この投稿を参照してください。これにより、「サブサイトに基づく」メンバーシップの問題が解決されます。SqlMembershipProvider