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.
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.