теоретический вопрос, но при работе с БД, это как раз и важно ведь

пример а.
допустим таблица прав доступа. скажем строчки выполняют роль пользователей, столбики - роль страниц. в ячейках находится число определяющее уровень прав.
возникает такой вопрос, и пользователи и страницы - суть число переменное. но если в добавлении строчек проблем не возникает, в добавлении столбиков чувствую затаённое зло. 
нормально ли иметь таблицу, которая от случая к случаю претерпевает изменения в ширину?
ведь клепать отдельную таблицу для каждой страницы глупо.
предупреждая возможные ремарки, читал http://php.russofile.ru/ru/translate/rights/phpgacl/ . всё-таки заманчиво иметь возможность контроллировать каждого пользователя на каждой странице
или всё же придётся группировать?

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

вопросы те же

спасибо

Табличка

Пользователь | Страница | Объект авторизации | Да/нет
Иванов              Стр. 1         Смотреть                       Y
Иванов              Стр. 1         Добавлять                     N
Петров.....

и т.д.

Добавлено через 57 секунд
Также вместо (вместе с) Пользователей могут быть группы...

правильно чувствуешь.

Нет, не нормально.

И не нужно отдельную таблицу. Можно одну таблицу с правими и одну таблицу со страницами.


Должно быть примерно так:
1 таблица с игроками.
2 таблица с этапами.
3 таблица с результатами на этапах (примерно так: <ID prim. key>, <ID этапа>, <ID игрока>, <Дата timestamp>, <результат, место или что-то еще что надо>)
4 таблица с результатами за год (эта таблица нужна, если результаты за год нельзя просчитать из предыдущей таблицы)

по принципу Kesh? 
но 50 страниц * 50 пользователей = 2500 тыс. записей, а так была бы одна таблица 50*50
а если больше? у меня есть вариант, где свыше 3000 зареганых пользователей
я так понимаю, без группирования не обойтись...

кстати, я чувствую зло, но не знаю, почему плохо, если таблица с изменяемым колич. столбцов?


т.е. ты хочешь сказать 15 чемпионатов * 16 этапов * 20 игроков * 3 (три отдельных независмых группы) = 14400 записей
и делать выборку из них? вроде не так много...
правда там потом будут разные операции на пхп для группировки в разных позах... наверно так и попытаем

спасибо

bars80080, База данных - она на то и придумана, чтобы хранить данные.. 30000 - 50000 строк это не так и много, главное правильно подбирай типы данных.

Примерно так, но это Kesh в общем виде показал. На практике, там еще несколько связанных таблиц понадобится.

а по поводу:

Потому что при изменении кол-ва столбцов или любом применении "ALTER TABLE" MySQL делает полную копию таблицы (при этом основную таблицу блокирует для изменения) делает изменения в копии и потом перезаписывает таблицу. Все время менять кол-ва столбцов в таблице в зависимости от каких-то условий, это в принципе противоречит принципу реляционных БД.

ну, изменения не предполагаются постоянными
порядка один раз в месяц

или отбросить идею как еретическую?   

  

bars80080, возьми и вместо пользователей используй группы... И уже записи с пользователями как записи более высокого приоритета...

P.S. 3000 пользователей * 3000 страниц на = всего-то 9'000'000 индексированных записей - поиск будет очень быстрым (ключики-то уникальные)...