使用Python集合类型实现ACL
目前我有如下表格：Pages、Groups、GroupPage、Users、UserGroup。 使用 pickled 集，我只需 3 个表即可实现相同的功能：页面、组、用户。
set 似乎是实现 ACL 的自然选择，因为与组和权限相关的操作可以用集合非常自然地表达。 如果我将允许/拒绝列表存储为腌制集，它可以消除多对多关系的少量中间表，并允许权限编辑，而无需进行大量数据库操作。
如果人类可读性很重要，我总是可以使用 json 而不是 cPickle 进行序列化，并在 Python 中操作权限列表时使用 set 。 直接使用 SQL 编辑权限的可能性极小。 那么这是一个好的设计理念吗？
我们使用 SQLAlchemy 作为 ORM，因此它很可能使用 PickleType 列来实现。 我不打算存储整个腌制的“资源”记录集，只存储由“资源”主键值组成的 set 对象。
Currently I have tables like: Pages, Groups, GroupPage, Users, UserGroup. With pickled sets I can implement the same thing with only 3 tables: Pages, Groups, Users.
set seems a natural choice for implementing ACL, as group and permission related operations can be expressed very naturally with sets. If I store the allow/deny lists as pickled sets, it can eliminate few intermediate tables for many-to-many relationship and allow permission editing without many database operations.
If human readability is important, I can always use json instead of cPickle for serialization and use set when manipulating the permission list in Python. It is highly unlikely that permissions will ever be edited directly using SQL. So is it a good design idea?
We're using SQLAlchemy as ORM, so it's likely to be implemented with PickleType column. I'm not planning to store the whole pickled "resource" recordset, only the set object made out of "resource" primary key values.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您要 pickle 集，则应该找到一个好的对象数据库（例如 ZODB） 。 在纯关系世界中，您的集合存储为 BLOBS，效果很好。 尝试在 ORM 情况下 pickle 集可能会导致 ORM 映射出现混乱的问题，因为它们大多假设纯关系映射，没有任何必须解码的 BLOB。
集合和其他第一类对象实际上属于数据库。 ORM 是一种 hack，因为有些人认为关系数据库“更好”，所以我们破解了映射层。
使用对象数据库，您会发现事情通常会更加顺利。
编辑
SQLAlchemy 有它自己的序列化器。
http://www.sqlalchemy.org/docs/05/reference/ ext/serializer.html
这既不是 pickle 也不是 cPickle。 然而，因为它需要可扩展，所以它的行为就像pickle一样。 对于您的目的来说，这将按照您需要的速度进行。 您不会一直反序列化 ACL。
If you're going to pickle sets, you should find a good object database (like ZODB). In a pure-relational world, your sets are stored as BLOBS, which works out well. Trying to pickle sets in an ORM situation may lead to confusing problems with the ORM mappings, since they mostly assume purely relational mappings without any BLOBs that must be decoded.
Sets and other first-class objects are really what belongs in a database. The ORM is a hack because some folks think relational databases are "better", so we hack in a mapping layer.
Go with an object database and you'll find that things are often much smoother.
Edit
SQLAlchemy has it's own serializer.
http://www.sqlalchemy.org/docs/05/reference/ext/serializer.html
This is neither pickle or cPickle. However, because it needs to be extensible, it will behave like pickle. Which -- for your purposes -- will be as fast as you need. You won't be deserializing ACL's all the time.
您需要考虑 DBMS 为您提供了什么，以及您需要重新实现哪些功能。
并发问题是一个大问题。 有一些竞争条件需要考虑（例如在不同线程和进程中发生多次写入并覆盖新数据）、性能问题（写入策略？如果你的进程崩溃并且丢失数据怎么办？）、内存问题（你的权限集有多大？它能全部放入 RAM 中吗？）。
如果您有足够的内存并且不必担心并发性，那么您的解决方案可能是一个不错的解决方案。 否则我会坚持使用数据库——它会为你解决这些问题，并且已经进行了大量的工作以确保它们始终将你的数据从一种一致的状态转移到另一种一致的状态。
You need to consider what it is that a DBMS provides you with, and which of those features you'll need to reimplement.
The issue of concurrency is a big one. There are a few race conditions to be considered (such as multiple writes taking place in different threads and processes and overwriting the new data), performance issues (write policy? What if your process crashes and you lose your data?), memory issues (how big are your permission sets? Will it all fit in RAM?).
If you have enough memory and you don't have to worry about concurrency, then your solution might be a good one. Otherwise I'd stick with a databases -- it takes care of those problems for you, and lots of work has gone into them to make sure that they always take your data from one consistent state to another.
对我来说，我会坚持以一种独立于用于访问它的特定编程语言的形式将持久信息保留在关系数据库中——就像我喜欢Python一样（而且这是一个很多），一些有一天我可能想从其他语言访问该信息，如果我选择 Python 特定的格式......我会后悔吗......
Me, I'd stick with keeping persistent info in the relational DB in a form that's independent from a specific programming language used to access it -- much as I love Python (and that's a lot), some day I may want to access that info from some other language, and if I went for Python-specific formats... boy would I ever regret it...
如果它简化了事情并且您不会大量编辑文件（或者很少编辑），我建议您就这样做。 当然，要考虑的第三个选择是使用 sqlite 数据库来存储这些内容。 有一些工具可以使这些内容易于人类阅读。
If it simplifies things and you won't be editing the file a whole lot (or it will be edited infrequently), I say go for it. Of course, a third option to consider is using a sqlite database to store this stuff. There are tools to make these easily human-readable.