Использование типа набора Python для реализации ACL

Question

В настоящее время у меня есть таблицы как: Pages, Groups, GroupPage, Users, UserGroup. С маринованными наборами я могу реализовать то же самое только с 3 таблицами: Pages, Groups, Users.

set кажется естественным выбором для реализации ACL, так как операции с группами и разрешениями могут быть очень естественно выражены с помощью множеств Если я сохраню списки разрешений / запретов в виде маринованных наборов, это может исключить несколько промежуточных таблиц для отношения «многие ко многим» и разрешить редактирование разрешений без множества операций с базой данных.

Если важна читаемость человеком, я всегда могу использовать json вместо cPickle для сериализации и использовать set при манипулировании списком разрешений в Python. Маловероятно, что разрешения когда-либо будут редактироваться напрямую с использованием SQL. Так это хорошая идея дизайна?

Мы используем SQLAlchemy в качестве ORM, поэтому он может быть реализован с помощью столбца PickleType. Я не планирую хранить весь подобранный набор записей «ресурсов», только объект set, состоящий из значений первичного ключа «ресурсов».

Answer 1

Если вы собираетесь выбирать наборы, вы должны найти хорошую базу данных объектов (например, ZODB ). В чисто реляционном мире ваши наборы хранятся как BLOBS, что хорошо работает. Попытка выбора наборов в ситуации ORM может привести к путанице в проблемах с отображениями ORM, поскольку они в основном предполагают чисто реляционные отображения без каких-либо больших двоичных объектов, которые должны быть декодированы.

Наборы и другие первоклассные объекты действительно то, что принадлежит базе данных. ORM - это хак, потому что некоторые люди думают, что реляционные базы данных «лучше», поэтому мы взламываем на уровне отображения.

Пройдитесь по объектной базе данных, и вы обнаружите, что вещи часто намного плавнее.

---

Редактировать

SQLAlchemy имеет свой собственный сериализатор.

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

Это не маринад и не маринад. Однако, поскольку он должен быть расширяемым, он будет вести себя как рассол. Который - для ваших целей - будет так быстро, как вам нужно. Вы не будете десериализовывать ACL все время.

Answer 2

Я бы хотел сохранить постоянную информацию в реляционной БД в форме, не зависящей от конкретного языка программирования, используемого для доступа к нему - так же, как я люблю Python (а это лот ) Когда-нибудь я захочу получить доступ к этой информации с какого-то другого языка, и если я перейду к специфическим для Python форматам ... мальчик, я бы когда-нибудь пожалел об этом ...

Answer 3

Вам необходимо подумать, что СУБД предоставляет вам, и какие из этих функций вам нужно реализовать. Проблема параллелизма является большой. Необходимо учитывать несколько условий гонки (например, множественные записи, происходящие в разных потоках и процессах и перезапись новых данных), проблемы с производительностью (политика записи? Что, если ваш процесс завершится сбоем и вы потеряете данные?), Проблемы с памятью насколько велики ваши наборы разрешений? Все ли это умещается в оперативной памяти?).

Если у вас достаточно памяти и вам не нужно беспокоиться о параллелизме, тогда ваше решение может быть хорошим. В противном случае я бы придерживался баз данных - они позаботятся об этих проблемах для вас, и много работы было сделано для того, чтобы они всегда переносили ваши данные из одного согласованного состояния в другое.

Answer 4

Если это упрощает вещи и вы не будете много редактировать файл (или он будет редактироваться нечасто), я скажу, пойти на это. Конечно, третий вариант - использование базы данных sqlite для хранения этого материала. Есть инструменты, чтобы сделать их легко читаемыми человеком.