2014-02-20 181 views
5

我目前正在製作一個銷售訂閱作爲多租戶應用程序的web應用程序。我使用的技術是導軌。多租戶與租戶共享數據

但是,它不會是孤立的租戶使用當前的應用程序。

每個租戶都會創建產品並將其發佈到應用的個人實例中。每個租戶都有自己的用戶羣。

有問題的規範是租戶可能會將其產品分享給其他租戶,以便他們可以轉售。

說明:

FruitShop銷售蘋果橘子和西紅柿。
VegetableShop出售蘿蔔和胡椒鍾。

Fruitshop將西紅柿分享給其他商店。

VegetableShop決定從共享 項目的可用列表中獲取西紅柿,並將其添加到其庫存。

現在顧客瀏覽蔬菜商店會看到蘿蔔,胡椒鈴和番茄。

正如你所猜,select products where tenant_id='vegetableshop_ID'將無法​​正常工作。

我想這樣做是一個多對多的關係以某種tenant_to_product表中,將有tenant_idproduct_idprice_id甚至發佈開始,結束日期。並且產品將是tenant_creator_id替換tenant_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引用原產品。

我不確定這會是一個好主意,像這樣實現這個約束,你建議我做什麼?我打算做些什麼愚蠢的事情,還是一個不錯的主意?

回答

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 structures?

2

多租戶似乎明顯的答案,因爲您提供多個客戶端的系統。

然而,作爲替代方案,也許考慮轉售商的「服務層」,這樣可以實現一定程度的隔離,同時仍然提供整合。吸取經銷商賬戶與亞馬遜等第三方的合作關係。

我意識到這是非常抽象的推理,但也許考慮到比數據層更高層的集成可能是有益的。

從在數據層級嚴格實施多租戶的經驗來看,我們發現租戶有時必須在業務層(如經銷商的想法)上操縱,以致租賃成爲一個棘手的概念。所以儘早考慮替代方案可能有所幫助