2009-04-26 39 views
1

目前我有像這樣的表格:Pages, Groups, GroupPage, Users, UserGroup。用醃製的套餐,我可以只用3張桌子來實現同樣的事情:Pages, Groups, Users使用Python設置類型來實現ACL

set似乎是實現ACL的自然選擇,因爲組和權限相關的操作可以很自然地用集合表示。如果我將允許/拒絕列表存儲爲醃過的集合,它可以爲多對多關係消除幾個中間表並允許在沒有許多數據庫操作的情況下編輯權限。

如果人的可讀性很重要,我總是可以使用json而不是cPickle進行序列化,並在Python中操作權限列表時使用set。使用SQL直接編輯權限的可能性非常小。那麼這是一個好的設計理念嗎?

我們使用SQLAlchemy作爲ORM,因此很可能會使用PickleType列實現。我不打算存儲整個醃製「資源」記錄集,只有set對象由「資源」主鍵​​值組成。

回答

3

如果你要泡菜,你應該找到一個好的對象數據庫(如ZODB)。在一個純粹的關係世界裏,你的集合被存儲爲BLOBS,效果很好。嘗試在ORM情況下醃菜集可能會導致ORM映射的混淆問題,因爲它們主要假定純粹的關係映射,而沒有任何必須解碼的BLOB。

集合和其他第一類對象實際上屬於數據庫。由於一些人認爲關係數據庫是「更好」的,所以ORM是一種黑客攻擊,所以我們在映射層入侵。

使用對象數據庫,你會發現事情往往更平滑。


編輯

SQLAlchemy中有它自己的序列。

http://www.sqlalchemy.org/docs/05/reference/ext/serializer.html

這既不是鹹菜或cPickle的。但是,因爲它需要可擴展性,它會表現得像醃菜。哪些 - 爲了您的目的 - 將會盡可能快地滿足您的需求。您不會一直反序列化ACL。

+0

我們正在使用SQLAlchemy。 PickleType是否可以接受?它使用泡菜還是cPickle? – Imran 2009-04-26 11:46:04

2

您需要考慮一下DBMS爲您提供的功能以及您需要重新實現哪些功能。 併發性問題是一個很大的問題。有幾種競爭條件需要考慮(例如在不同的線程和流程中進行多次寫入並覆蓋新數據),性能問題(寫策略?如果你的進程崩潰了,你失去了你的數據?),內存問題(你的權限集有多大?是否全部適合RAM?)。

如果你有足夠的內存,你不必擔心併發性,那麼你的解決方案可能是一個很好的解決方案。否則,我會堅持使用數據庫 - 它爲您解決了這些問題,並且大量的工作已經進入到它們中,以確保它們始終將數據從一個一致的狀態轉移到另一個狀態。

1

如果它簡化了一些東西,而且你不會編輯很多文件(或者很少編輯它),那麼我會說。當然,要考慮的第三個選擇是使用sqlite數據庫來存儲這些東西。有些工具可以使這些文件易於人類閱讀。

2

我,我會堅持保持關係數據庫中的持久性信息,與獨立於用於訪問它的特定編程語言的形式 - 就像我喜歡Python(這是一個lot),有一天我可能想要從其他語言訪問這些信息,如果我使用特定於Python的格式...男孩會永遠後悔它...