Miha, Судя по твоим рассуждениям, по которым ты собираешься писать свою CMS или как ты ее назовешь,
У тебя понятия о говнокоде самые отдаленные...
А пример говнокода из JohnCMS, я более чем уверен что ты где то на форумах подцепил.
И вобще для меня JohnCMS не эталон, скажу чесно с мобильными движками никогда дела не имел.
Сделал не один десяток сайтов на MODx, и с каждым из них, не перестаю хвалить разработчиков.
Впрочем дальнейшие дискуссии не имеют смысла, дабы не засорять тему никому не нужными постами. Пусть каждый останется при своем мнении.

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

Ты хранишь данные о группах, как BOOL? Если да, то будет экономия памяти. Насчет скорости тоже подозреваю, что будет работать быстрее и лучше кэшироваться. Ну и вообще 20 полей в таблице как-то не очень, на мой взгляд.

MySQL - реляционная СУБД, так что выбора парадигмы нет в любом случае.

"Ну и вообще 20 полей в таблице как-то не очень, на мой взгляд." - тоже так пока думаю, поэтому и интересно, как бы это получше сделать.
"Ты хранишь данные о группах, как BOOL?" - собираюсь хранить.

можно таблицу зависимостей сделать, где будет несколько полей, которые можно отметить bool для каждой операции, более гибко

Koenig, а подробнее можно?

Miha, ид юзерид ф1 ф2 ф3 ...
ставим галки на поля какой либо функции для нужного юзера
новая функция появилась, добавляем поле в таблу

Koenig, я так и хочу, просто ImIee выше написал, что 20 полей многовато будет.

Miha, ну думаю можно объединить, какие либо функции, полей станет меньше, гибко конечно, можно все же как я ранее написал с ини, или еще одну таблицу завести, то есть в первой три поля для галок, админ , суперадмин, модер, и во второй более конкретные поля, опять же несколько, удалить, добавить, редактировать, читать

Koenig, в этом способе плюс получается только в том, что разгружается таблица пользователей. Кода и запросов же будет больше (точнее, их объём), если я всё правильно понял.
Ещё у меня была такая идея. Есть таблица групп:
| id | name |
А в таблице пользователей добавляется единственное поле, где перечислены группы, в которые входит пользователь:
|id|login|rights|
|12|admin|1,2,3|
Потом считываем `rights`, эксплодим (разбиваем), проверяем в цикле, состоит ли пользователь в определённой группе и действуем по обстоятельствам.
Плюс в том, что гибкость теряется на самую малость (главное - правильно считывать и изменять `rights`), пользователю добавляется только одно поле вместо множества.
Минус, возможно, в том, что по одной таблице пользователей не понятно, к каким группам принадлежит пользователь, но это же не так и важно. Точнее, вообще не важно.

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