Как хранить в БД права доступа?

Да, пагинация по характеристикам, хранящимся в колонках таблицы content.
Пагинация вполне обычная — N штука на страницу. Если всё уложится в качественный запрос, то будет через limit offset конечно.

Как хранить в БД права доступа?

Но вопрос-то состоит не в том, как впринципе проверить права — это не представляет проблемы. Вопрос в том, как быстро выбирать из БД строки, права на которые у тебя есть

Как хранить в БД права доступа?

1. Впринципе да. Об этом уже выше упоминали. Ребилдить такие списки по доавлению/удалению друзей.
2. Понятно, что OR и union — это, здесь, альтернатива друг другу. Union плох по следующей причине: Самый популярный вариант выбора прав доступа будет «доступно всем». Т.е. с одной стороны от union'а будет стоять select чуть ли не всей таблицы content. Пагинировать select с таким union'м внутри — это temporary table + filesort практически по всем rows

ИЛИ. Идею понял. Она сродни предложенному Vampiro: использование особого признака для «для друзей»

Составляя вопрос, я намеренно откинул все, что показалось мне не обязательным, чтобы увеличить шансы на ответ (простыню никто читать бы не стал).

В реальности к моим правилам добавляются ещё 2 вида правил:
— доступно всем
— доступно зарегистрированным
— доступно друзьям
— доступно конкретному другу/списку друзей
— доступно кругу(кругам) друзей

(круг — подмножество друзей пользователя, организованых в одну группу, for example «коллеги»)

а может случиться так, что эти правила пополнятся ещё какими-то

Именно поэтому я всё ещё не могу сказать, что нашёл подходящее решение

Как хранить в БД права доступа?

>> нужно хранить в виде bolean у content
Сомнительно. Флаги плохо или вообще не поддаются индексированию. Гораздо быстрее в качестве флага использовать «наличие строки в приjoinенной таблице».
С помощью этого можно разве что незначительно ускорить проверку прав конкретной строки

>> так ли важно разделять эти понятия
Да, конечно. Правильно ли я понял, вы предложили вместо флага «все» напрямую перечислять всех пользователей в таблице? Это логически не подходит, потому как вновь регистрирующиеся пользователи должны видеть такой контент. Но главное, что «доступно всем» это самое популярный вариент выбора.

>> Дальше, никогда не нужно надеяться на чистую реляционную модель. Делайте дополнительную копию на все, что читается чаще чем пишется в удобном для этого месте.
Абсолютно не зацикливаюсь на нормализации в этом вопросе, но даже денормализованного качественного решения найти пока не могу

>> запросов вида like '%12345,%',
Не представляю, где бы я мог воспользоваться таким заведомо неиндексируемым (MySQL) выражением. Опять же, разве что для того, чтобы незначительно ускорить проверку прав конкретной строки

Как хранить в БД права доступа?

Не то, чтобы планировал решать именно так, но в варианте с union это бы выглядело примерно следующим образом:

select c.* from content c
join content_share_wide csw on csw.content_id = c.id
where csw.type = 1

union

select c.* from content c
join content_share_wide csw on csw.content_id = c.id
join user_friend uf on c.user_id = uf.user_id
where csw.type = 2 and uf.friend_user_id = ?

union

select c.* from content c
join content_share_user csu on csu.content_id = c.id
where csu.user_id = ?

Вся схема изложена в вопросе. Это таблицы content, user и user_friend + потенциальные таблицы, в которых бы хранились права доступа, о которых собственно и вопрос.

Как хранить в БД права доступа?

С "-1" не понятно: тут нет проверки, что текущий пользователь является другом

Как перекрашивать дочерние элементы при наведении мышки на элемент li?

Жесть какая.

Крастье от this

$(this).find(".circle-menu-work").css({"background-color":"#70CF70"});
$(this).find(".legend-v-menu-work a").css({"color":"#70CF70"});

з.ы. но CSS'ом конечно всяко кошернее