Не очень понимаю, зачем нужно переводить в двоичную форму. Если нужно проверить, состоит ли пользователь в группе - if($groups & $group_number)

ImIeee, спасибо, так гораздо легче.

насколько понял проблема в группах и правах в группах?
я б сделал так, есть 3 таблицы:
- юзер
- группа
- группа-юзер

по первой таблице думаю нет вопросов.
во второй храним айди, название, описание и тому подобное.
в третией храним связи юзеров и групп, т.е такая структура user_id | group_id | permission(права).

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

P.S. немного рекламы, на django эти отношения делаються за пару минут с готовой админкой, да и запросы легко делать. пример:
user # юзер
g=Group.objects.get(id=1) # выбрали группу
g.user.get(id=user.id) # если юзер не в группе вызоветься исключение
g.user.add(user=user, permission="admin") #добавить юзера в группу с правами администрации

ну и так дальше. Будет желание узнать про джанго, пишите

не путай ORM и РСУБД, хотя можно, но опять же не так все просто

орм это обвертка к субд, просто я описал, как бы я сделал и какие бы вышли тогда таблички(на основе моих классов)

Способ, по идее, хорош тем, что можно быстро сделать запрос "все пользователи в группе". С другой стороны, третья таблица будет занимать больше места.

ImIeee, ну если зацикливаться на количестве таблиц и столбцов много велосипедов делать прийдеться.
Но там много легких запросов, в каких группах состоит юзер, где админ, состоит ли юзер в группе и т.д.

При чем тут велосипеды? Программы по составлению оптимальной структуры таблиц нет, поэтому приходится все делать самим. Опять же, я не призываю ни на чем зацикливаться. Первый и третий запрос выполнятся так же, если не быстрее, при использовании битовых полей. Выполнение второго можно ускорить, если поставить индекс на поле, использовать самый старший бит и самому задать границу поиска.

просто вы сейчас говорите про низкоуровневые управление базой, от которого я отвык. я пишу на джанго, и там такие вопросы решаються подругому, делаеттся три класса(юзер, группа, юзер-группа), и привязываються юзер с группой через MTM(ManyToMany), через таблицу юзер-группа. На писать такую связь папу мин делов, потом на основе классов создадуться таблицы. И не возникает вопрос о структуре базе, и так ясно, что с чем связанно и как.

Да ладно, можно вообще взять какой-нибудь готовый модуль авторизации и не возиться. С другой стороны, будет некоторое падение производительности, больший расход памяти, костыли для нетрадиционных решений. Ну или какой-нибудь раздутый компонент в конечном итоге более сложный, чем собственно сам sql.

сразу ясно что вы не вникпли в джанго, там и так готовый модуль есть, но его переделать не что не ммешает, + там можно делать свои sql запросы, и почти под все нетрадицтонные проблемы есть решения.
Хотя, я с вами согласен, что низкоуровневые запросы быстрее обработываються, но то что вы будите писать на пыхе, я могу написать минимум в раза два короче и быстрее, а сейчас скорость разроботки цениться выше, чем производительность, ведь всегда можно купить сервак помочнее.

Flaky, Разумеется, я вообще не знаю питон и не сужу о каких-либо конкретных возможностях На php, кстати, тоже полно фреймворков.