マルチテナンシーをサポートするために、既存のバンキング アプリを拡張する任務を負っています。このアプリは現在、約 100 社の企業にサービスを提供しており、ユーザー数は約 4,000 人です。そして、大きな成長の準備ができています。
詳細は少し複雑なので、ここに簡単な歴史があります:
もともと、このポータルは、3 つのタイプ/役割のアカウントを管理する 1 つの住宅ローン会社が使用するために作成されました。
- 内部 - すべてのユーザー、銀行、ブローカー、住宅ローン ファイルを管理できる住宅ローン会社の従業員
- クライアント - ユーザーと住宅ローン ファイルのみを管理できる銀行員
- ブローカー - 独立した請負業者は、住宅ローンのファイルにのみアクセスできます
順風満帆、そしてクライアント #2 の登場: 新しい住宅ローン会社ごとに個別のインスタンスが作成されました。制度を採用したもの。別々のインスタンスは、必然的に別々のバージョンに変形しました。これらは現在、単一の構成可能なバージョンに移行されていますが、住宅ローン会社ごとに個別のインスタンスがまだ存在しています。
最初のひねりは、ますます多くのブローカーが複数の住宅ローン会社で働いており、たとえば Citi、GMAC、Chase、BoA などに別々のログインを維持することを余儀なくされていることです。
2 つ目のひねりは、銀行の従業員が住宅ローン会社のインスタンスごとにログインを維持する必要があることです。(別の DB のため)
3 つ目のひねりは、より多くの銀行が、住宅ローン会社が持っているような事例を望んでおり、提携しているすべての住宅ローン会社が銀行に来ることを要求していることです (部分的には、上記のひねり #2 によって引き起こされます)。
実際には、あるインスタンスで住宅ローン会社にファイルを割り当てる銀行があり、住宅ローン会社の従業員は銀行のインスタンスにログインし、データを自分のインスタンスに二重に入力しています。すべてが同じデータベース サーバー上にあります。
したがって、この N 乗の膨張を 1 つのマルチテナント DB に統合し、クライアントの重複アカウントと重複データ入力を排除したい/必要があります。クライアントが銀行の場合もあれば、住宅ローン会社の場合もあります。銀行と住宅ローン会社のソーシャル ネットワークのようなものです。
質問: 1. これは非常に標準的な MT 実装ですか? 2. MT ソリューションで共有オブジェクトを使用することは一般的ですか? (つまり、システム内の GMAC は 1 つだけです) 3. 参考になるサイトはありますか? 4. MT 以前に関係があった場合を除き、銀行、ブローカー、住宅ローン会社を互いに隠すかどうかについての提案はありますか? 1 つのオプションは、それをオープンにすることです。ディレクトリをすべて新しい銀行、ブローカー、および住宅ローン会社とネットワーク化することができます。または、それを閉じて、すべてのエンティティを非表示にし、各エンティティが別のエンティティの GUID を提供して発見してリンクするように要求します。彼ら。
MT ベータ版について私が持っていた基本的なスキーマのアイデア:
1. すべてのインスタンスからのすべての個別のユーザー アカウントを含むユーザー テーブル 2. すべてのインスタンスからのすべての住宅ローン会社と銀行を含む組織テーブル 3. UserOrgLink テーブルは、ロールを持つユーザーを組織にリンクします 4. RoleType テーブル 5 . ほとんどのテーブルの OrgID 列
私はすべての意見、アイデア、批判を歓迎し、尊重します。