Делаю CMS (для тренировки и приоберетения опыта). На данный момент дошел до раздела "Управления пользователями". Там есть группы пользователей, например, "Администраторы", "Партнеры", "Клиенты", "Дилеры"... И так далее. Когда создаю нового пользователя, то у каждого пользователя одинаковые поля: имя, фамилия, логин,пароль, мыло, сайт... А я хочу сделать так, чтобы у каждой группы пользователей были свои поля. У дилеров: город, страна, телефон, название компании. У клиентов: фио, мыло, сайт, включена ли подписка. У Партнеров: название компании, контактное лицо, факс.

В общем, у каждой группы юзеров свои замуты. Группы могут создаваться и удаляться. То есть должна быть такая гибкость. Как лучше реализовать такую структуру? Четыре таблицы: users, users_groups, users_fields, users_values (заполненные поля)? Так? Но это уж как-то черезчур, по-моему.

Кто какую схему может предложить?

не users_fields, а groups_fields, ибо определения набора информационных полей относится к группе, а никак не к отдельному пользователю. к пользователю относится только значение... 
Кста, это лучше в "Общие вопросы по базам данных"
Смотри. 
users - в этой таблице хранятся данные, единые для пользователей, независимо от группы.
iduser
name
login
password
registerDate
... etc ...
fields - список полей, которые должен будет заполнить юзер
idfield
name
groups - в этой таблице хранятся названия групп
idgroup
name
users_groups - здеся принадлежность пользователя какой-либо группе
idgroup
iduser
groups_fields - определяем, какие поля необходимо заполнить при принадлежности юзера к определённой группе
idgroup
idfield
users_values - данные о заполненных пользователями полях
iduser
idfield
value

skyboy, то есть считаешь эта схема все-таки нормальная? я её уже реализовал, но возникли сомнения по поводу её возможностей и влияния на загрузку процессора на сервере...

и нифига не много. а если у тебя мультиязычный фейс, то тебе надо будут ещё таблицы:
groups_names
idgroup
idlanguage
name
fields_names
idfield
idlanguage
name
Я уже молчу про то, что некоторые values могут быть ограничены в своём выборе(например, выбор страны только из списка, год - только с 1921 по текущий и так далее)... Тогда количество таблиц увеличится...

Добавлено @ 14:41 
Kirill Baranov, что значит "сомнения по поводу её возможностей"?

skyboy, да про возможности уже сомнения развеялись. Система получается очень гибкой. А для мультиязычности я собираюсь по-другому реализацию делать. Кол-во таблиц не буду увеличивать, просто с помощью ALTER для МуСКЛа буду добавлять столбцы типа name_lang, где lang  - ID языка.... Короче, сложно все так... бошка едет.

например, данные о пользователе $id с точки зрения группы $idgroup

или полные данные о пользователе $iduser:

Что ещё надо? Поиск? 
Положим, надо найти всей юзерей, входящих в группу $idgroup, у которых свойство $idfield равно значению $value

Чего ещё может потребоваться?

Добавлено @ 14:55 

наверное, и такой подход не идеален... однако вполне удобоварим 
А касательно языка - непонятно, как ты в одной записи в, скажем, fields, забьёшь названия на 5-7 языках. Это же связь один-ко-многим. Тут нужна отдельная таблица, иначе при работе хлопот не оберёшься...

Добавлено @ 14:57 
поищи информацию про нормализацию и нормальные формы. в очень некоторых случаях можно отступить от следования нормальным формам(один случай на тысячу случается, наверное), однако почти всегда следование им сильно(очень сильно) облегчает жизнь тому, кто будет разработанную структуру использовать...

Спасибо большое) Буду еще думать как делать) Ведь идеала все равно не добиться, а тебе плюс

будут ещё вопросы - обращайся. как раз сейчас над CMS работаю... Только до авторизации ещё не добрался 

Добавлено @ 15:14 

а идеала нет, потому идостичь его невозможно.
зы А ты ещё права прикрути группам.... На запись, удаление, изменение...