其他實體的多用戶權限

Question

我們公司正在從單一用戶應用程序遷移到多個問題。我們的設置是用戶將擁有一個產品，並且該擁有權是通過一個外鍵。由於他們擁有產品，他們將有權執行產品上的所有功能。如果您不擁有產品並且不是管理員，則無法訪問產品或其任何功能。

現在我們試圖打開對產品的訪問權限，直至與相應所有者分組在一起的其他用戶進行協作。包括所有者在內的這些其他用戶可能基於一組權限具有有限的功能。權限的範圍已經被設計爲基於

1. 的人到產品的所有權關係（FK）
2. 通過Person_Product橋表
3. 人爲中心集團產品關係的人到產品的關係如果產品屬於一個並且只有一個組
4. 要組織的人員（Applicantion Wide Permissions），如果未聲明通過其他關係的權限，則該用戶默認權限。

這些關係已經實現，但系統在根據關係進行大量計算時出現了問題。例如獲取用戶對一系列產品的權限顯着影響了性能。另外我們系統的靈活性受到新的關係和抽象的限制。

數據庫方面，我將關係2看作是可以用來表示所有關係的行爲以及我們公司將被要求排在前面的任何未來抽象的基本塊。

我是否正確的這一思路？或者我們現在走在正確的軌道上嗎？任何有用的輸入將不勝感激。

相關技術被標記。

Answer 1

當涉及到這樣的應用程序時，嚴格規範化的關係數據庫可能是一個瓶頸。我還沒有看到這個解決方案，但是如果你考慮一些在標準化數據庫中被禁止的表，比如某種緩存，你可以加快速度。

我的方法是有一個嚴格規範化的數據庫部分包含實際數據和一個非標準化的部分作爲緩存...這兩個部分之間的更新是一種方式：從規範化部分緩存（在可能會重建緩存中的數據/異常情況，緩存可以重建）

優點是：您的每個用戶的權限可以被聚合（甚至可以作爲一個二進制對象）並且每個用戶/每個產品/等，只要權限來自緩存...取決於使用情況，這可以是非常快的

缺點是：更新緩存數據更復雜：您必須更新正常的數據庫，然後你必須更新緩存，否則你的更新將不會被緩存看到，直到它被重新綁定爲止......如果你的權限沒有每2秒更新一次，這個問題不會有太大的問題

加上：你必須實現和維護緩存和使用這個的應用程序...

所以有一個警告：即使這個可以（==它不能保證在任何情況下）速度非常快，只要還有其他選項，就不應該使用這種方法。 （你應該儘可能避免打破規範化;數據庫是否被正確地編入索引？是否可以將這樣的緩存設置在其他地方，即某個服務應用程序？）