5

現在、サブスクリプションをマルチテナント アプリとして販売する Web アプリを作成中です。私が使用している技術はレールです。

ただし、現在のアプリを使用してテナントを隔離するだけではありません。

各テナントは製品を作成し、アプリの個人用インスタンスで公開します。各テナントには独自のユーザー ベースがあります。

問題のある仕様は、テナントがその製品を他のテナントと共有できるため、再販できることです。

説明 ：

FruitShop では、リンゴ オレンジとトマトを販売しています。
ベジタブルショップでは、大根とペッパーベルを販売しています。

Fruitshop は他のショップにトマトを共有しています。

野菜店は、利用可能な共有アイテムのリストからトマトを取得し、在庫に追加することにしました。

これで、野菜屋をブラウジングしている顧客には、大根、ペッパー ベル、トマトが表示されます。

ご想像のとおり、 aは機能しselect products where tenant_id='vegetableshop_ID'ません。

、 、さらには開始日と終了日を公開する、ある種のtenant_to_productテーブルと多対多の関係を構築することを考えていました。また、製品は、元の所有者を知るためにテナント ID が tenant_creator_id に置き換えられる「ハーフ テナント テーブル」になります。tenant_idproduct_idprice_id

私には面倒に思えます。これを追加すると、自社製品のみを販売するショップであっても、複雑なクエリが必要になります。販売された製品を取得するのは複雑です。

select tenant_to_products.* 
where tenant_to_products.tenant_ID='current tenant' 
AND (tenant_to_products.product match publication constraints) 

for each tenant_to_product do
   # it will trigger a lot of DB call
   Display tenant_to_product.product with tenant_to_product.price

製品の非共有は、元の製品を参照するすべての tenant_to_products を変更する複雑な更新も意味します。

この制約をこのように実装するのが良い考えかどうかはわかりません。どうすればよいと思いますか? 私は何かばかげたことをするつもりですか、それともそれほど悪い考えではありませんか?

4

2 に答える 2

3

すでに解決したように、製品メカニズムへのより複雑なサブスクリプションが必要になります。あなたは正しい軌道に乗っているように聞こえます。

できるだけ情報を抽象化します。たとえば、テーブルを「tenant_to_product」と呼ばずに「tenant_relationships」と呼び、このテーブルの列として製品 ID を指定します。

次に、テナントがサービスを必要とする場合、テーブル全体を追加することなく、このテーブル「サービス ID」に列を追加するだけで済みます。

パフォーマンスのために、わずかな遅延で更新されるテナント関係を持つ読み取り専用データベース サーバーを使用できます。Azure または同様のクラウド サービスを使用すると、これを簡単に開始できます。ただし、ユーザー数が 100 万人を超える場合を除き、これはおそらく必要ありません。

検討することをお勧めします：

  • アクティブ/非アクティブ (野菜ショップは、栽培者がトマトにバグを含めるのをやめるまで、現時点では非常に欠陥があるため、トマトの販売を一時的に停止することを好む場合があります)

  • 「productRemoved」サービスなど、通知用のサーバー側サービス。これらのサービスは変更をまとめて処理し、ユーザーへのフィードバックをより迅速に提供します。

  • 情報を削除しないでください。代わりに、列「delete_date」と「delete_user_id」などを設定してください。

  • 製品、テナント、関係などに対する変更の完全な監査履歴。このテーブルは非常に大きくなるため、テーブルの更新を待って呼び出し元がブロックされないように、テーブルからの読み取りを避け、更新が非同期であることを確認してください。しかし、ビジネスの観点からはおそらく非常に役立つでしょう。

編集：

この関連する質問がまだ表示されていない場合は、役立つ可能性があります: How to create a multi-tenant database with shared table structure?

于 2014-03-05T22:55:28.853 に答える
2

システムに複数のクライアントを提供しているため、マルチテナンシーは明らかな答えのようです。

ただし、代替手段として、再販業者の「サービス層」を検討してください。これにより、統合を提供しながらある程度の分離が可能になります。再販業者のアカウントが Amazon などのサードパーティと連携する方法にインスピレーションを与えます。

これは非常に抽象的な推論であることは承知していますが、おそらくデータ層よりも上位層での統合を検討することが有益である可能性があります。

データ層レベルでマルチテナンシーを厳密に実施した経験から、テナンシーがトリッキーな概念になるほど、ビジネス層でテナンシーを操作する必要がある場合があることがわかりました (再販業者のアイデアなど)。そのため、早い段階で代替案を検討することが役立ちます。

于 2014-03-06T22:57:18.003 に答える