Большинство оптимизаций производительности обычно сводится к тому, чтобы тяжёлую работу выполнять не тогда, когда нужно быстро получить результат, и вообще снизить объём работы.
А большинство оптимизаций надёжности, скорости разработки и вообще стоимости владения кодом обычно сводится к его уменьшению и упрощению.
Поэтому в любом случае придётся в каких-то моментах выбирать или-или.
На счёт производительного слоя доступа, я делаю обычно примерно так:
Вот у меня есть объекты, настройки доступа к которым влияют на другие объекты, доступ к которым тоже настраивается (буду использовать в качестве примера папки).
При смене настроек доступа к папке для каждой подпапки я вычисляю эффективные настройки доступа. Т.е. посколько запреты доступа на родительской папке добавляются к запретам на дочерней, то эффективные настройки доступа дочерней включают и те запреты, и эти.
Так вот для каждой папки я храню не только изначальные настройки доступа, которые юзер задал конкретно этой папке, но и все запреты всех родительских папок до корня.
Так мне при решении о том, давать ли доступ к каждому объекту не нужно загружать из БД настройки доступа всех родительских объектов. Но за то изменение настроек доступа замедляется. Обычно это ок.
Если этого недостаточно, то вот как я оптимизирую получение списка доступных объектов.
Обычно все выборки объектов можно как-то систематизировать. Например, в случае с папками и файлами выборки бывают такими:
1. Список подпапок папки A.
2. Список файлов папки А в сортировке по рейтингу.
3. Список файлов папки А в сортировке по дате создания.
4. Список файлов папки А и всех её подпапок в сортировке по рейтингу.
5. Список файлов папки А и всех её подпапок в сортировке по дате создания.
Настройки доступа к папкам меняют видимость целых кусков таких выборок. Например, для выборки №1 - для каких-то юзеров может появиться или пропасть один элемент из-за изменения на нём настройки доступа.
Для выборок 2 и 3 может пропасть или появиться сразу всё содержимое выборки.
Для выборок 4 и 5 может пропасть или появиться та часть выборки, которая находится непосредственно в папке и изменённой настройкой доступа, а так же в её подпапках.
Так вот можно нарезать уникальных фрагментов всех выборок так, что каждый фрагмент будет содержать файлы с уникальным набором запретов доступа. Потом эти фрагменты нужно где-то хранить. Это производная выборка от целевой.
Т.е. если целевая выборка - это просто выборка всех файлов папки в какой-то сортировке, а слой доступа уже после выборке должен нафильтровать только доступные, то у нас будет не так, ибо это дорого. У нас заранее будет готов список объектов, доступный по определённому уникальному набору запретов.
А когда происходит запрос на выборку доступных объектов, мы узнаём, какие вообще есть фрагменты, какие у них настройки доступа, какие из них доступны нашему юзеру.
Потом выбираем из БД содержимое всех доступных фрагментов и, поскольку внутри это сортированные списке, сливаем их занедорого.
Так же недорого можем получить такой список со смещением. Т.о. можем получать не весь список целиком, ведь он может быть очень большим, но и брать его частями. Например, для постраничного вывода.
Но это будет работать только если настройки доступа к папкам не особенно разнообразны. Обычно это так и есть.
В общем вот в таком ключе обычно всё.
