目前我有这样的表：Pages, Groups, GroupPage, Users, UserGroup. 使用腌制集，我只需 3 个表即可实现相同的功能：Pages, Groups, Users.
set似乎是实现 ACL 的自然选择，因为组和权限相关的操作可以用集合非常自然地表达。如果我将允许/拒绝列表存储为腌制集，它可以消除一些用于多对多关系的中间表，并允许在没有很多数据库操作的情况下进行权限编辑。
如果人类可读性很重要，我总是可以使用 json 而不是 cPickle 进行序列化，并set在 Python 中操作权限列表时使用。使用 SQL 直接编辑权限的可能性很小。那么这是一个好的设计理念吗？
我们使用 SQLAlchemy 作为 ORM，所以它很可能用PickleTypecolumn 来实现。我不打算存储整个腌制的“资源”记录集，只存储set由“资源”主键值组成的对象。
如果你要腌制集合，你应该找到一个好的对象数据库（比如ZODB）。在纯关系世界中，您的集合存储为 BLOBS，效果很好。尝试在 ORM 情况下腌制集合可能会导致 ORM 映射出现混淆问题，因为它们大多假设纯粹的关系映射没有任何必须解码的 BLOB。
集合和其他一流的对象确实属于数据库。ORM 是一种 hack，因为有些人认为关系数据库“更好”，所以我们在映射层中进行 hack。
使用对象数据库，您会发现事情通常要顺畅得多。
编辑
SQLAlchemy 有它自己的序列化器。
http://www.sqlalchemy.org/docs/05/reference/ext/serializer.html
这既不是泡菜也不是 cPickle。但是，因为它需要可扩展，所以它的行为就像泡菜一样。哪个 - 出于您的目的 - 将与您需要的一样快。您不会一直反序列化 ACL。
您需要考虑 DBMS 为您提供了什么，以及您需要重新实现哪些功能。并发问题是一个大问题。有一些竞争条件需要考虑（例如在不同的线程和进程中发生多个写入并覆盖新数据），性能问题（写入策略？如果您的进程崩溃并且丢失数据怎么办？），内存问题（你的权限集有多大？它们都适合 RAM 吗？）。
如果您有足够的内存并且不必担心并发性，那么您的解决方案可能是一个不错的解决方案。否则我会坚持使用数据库——它会为您解决这些问题，并且已经对它们进行了大量工作以确保它们始终将您的数据从一个一致的状态带到另一个。
我，我会坚持以一种独立于用于访问它的特定编程语言的形式将持久性信息保存在关系数据库中——就像我喜欢 Python（而且很多）一样，有一天我可能想要访问它来自其他语言的信息，如果我选择特定于 Python 的格式……男孩我会后悔吗……
如果它简化了事情并且您不会大量编辑文件（或者它会不经常编辑），我说去吧。当然，要考虑的第三种选择是使用sqlite数据库来存储这些东西。有一些工具可以使这些易于人类阅读。