2

私はSalesforce.comと数年間仕事をしてきましたが、頭の体操/課題として、彼らが「データベース」を処理する方法と同様の解決策を考え出そうとしました(はい、彼らは実際にはテーブルを使用していないことを知っています.ビュー、しかしメタデータ)。これは、最初の予想よりもはるかに困難であることが判明しました。

SFDC を再発明しようとしているわけではないことに注意してください。マルチテナント実装の解決策を模索しようとしていたところです。

要件

  1. 顧客固有のデータを他の顧客に公開したり、顧客固有のデータベースを使用したりせずに、複数の顧客/テナントを処理できる必要があります。
  2. すべての顧客は、一連の標準テーブルへの標準化されたアクセス権を持っている必要があります (つまり、Select * from Account は、要求している顧客に関連付けられたすべてのアカウントを返します)。
  3. すべての顧客は、すべての標準テーブルにカスタム フィールドを追加できる必要があります。
  4. すべての顧客がカスタム テーブルを追加できる必要があります。
  5. 顧客のカスタム フィールドは、標準テーブルに「追加」された場合でも、その顧客にのみ表示される必要があります。
  6. 顧客のカスタム テーブルは、その顧客にのみ表示される必要があります。
  7. 理想的には、このソリューションは 1 つの RDBMS に固有のものではありません。(PostgreSQL の search_path には依存できません)

私の解決策

  1. 標準テーブルが「プライマリ」スキーマに格納されるマルチスキーマ データベース設計を作成します ( Primary.TrueAccounts)。
  2. Primary.TrueAccounts顧客ごとに、ベース テーブルを含む個別のスキーマを作成して、顧客を( )にリンクする FK を保持しますCust1.AccountCustomFields。このテーブルは、カスタム フィールドが追加される場所です。
  3. 顧客のカスタム テーブルは、そのスキーマにのみ追加されます。
  4. 標準テーブルごとに、標準列をその顧客のカスタム列と結合した顧客スキーマ左のビューを作成します ( CREATE VIEW Cust1.Accounts AS SELECT t1.field1, t1.field2, t2.* FROM Primary.TrueAccounts AS t1 LEFT JOIN Cust1.AccountCustomFields AS t2 ON t1.id = tw.Accountid WHERE t1.CustomerId = 1)

この基本的なソリューションを MySQL ワークベンチでモックアップしたので、少なくとも説明どおりに可能であることはわかっています。

私の究極の質問は「どうやってやったの？」です。上記の要件を達成するためのより良い/標準/醜くない/より効率的な方法はありますか?

4

0 に答える 0