USERS
-user_id
-user_name
-user_type

USERS_TYPE1_INFO
-user_id
-ICQ
-e_mail

USERS_TYPE2_INFO
-user_id
-zip_code
-home_tel
-mobile_tel

так можно и сообщения друг другу писать, и связывать...
вот только геморно добавлять типы...
можно по другому
USERS - список пользователей
-user_id
-user_name
-type_id

USERS_INFO - информация о пользователях
-user_id
-field1 (varchar)
-field2..
-field3..
...
-field10 (смотря сколько может быть свойств у пользвателя)
и
USERS_TYPE - описание типов пользователей, и полей для этого типа в тбл USERS_INFO
type_id
type_name
field1_name
field2_name
...
field10_name

alver
Тяк...)
user_id в таблицах типов пользователей в первом варианте я так понимаю внешние ключи, мда?)
Второй вариант мне кажется не целесообразным. Ведь в таблице USERS_INFO будут пустые поля. Оно конечно лучше, чем одна большая, но просто, к примеру конкретно у меня есть тип юзера "клиент" у которого есть около 20 полей(его контактная инфа), которые есть тока у него. И эти 20 полей для остальных 4 типов будут как бы ничем) Это конечно может и нормально, просто мне вот интересно, какой тут оптимальный подход.
первый вариант удобен, когда у вас 2...5 типов пользователей, и в процессе жизни ИС они не будут добавляться, ну или крайне редко.
сущность пользователи - одна, одна сплошная нумерация, то есть в дальнейшем, в можете, например, к договру одинаково привязать как физическое лицо, так и юр.лицо.
это раз. во-вторых, в программах, оперируя "пользователями", нас интересуют не их телефоны, а UID, пароли, ник/имя...это всё в USERS... и когда это всё будет отдельно от кучи текстовых полей, проиндексированно - это будет быстрее работать.
понятно, что если в программе вы просматриваете список физ лиц, то таблица users джойница с USERS_TYPE1_INFO (например), а когда список юр лиц, то USERS_TYPE2_INFO. все представления для пользователя через VIEW

для физиков и юриков считаю надо делать также, не 2-мя таблицами а 3-мя... например база по "земельным участкам"... объект права - участок, а субъект права - физик/юрик... договор, аренда привязывается, в первую очередь, к субъекту права, а уже потом, физик, или юрик.
другое дело, что это "усложняет" формы просмотра/редактирования, но ИМХО упрощает проектирование/программирование в дальнейшем.

второй вариант, по сути первый, но с возможностью добавления/удаления типа пользователей без модификации объектов БД.
USERS_INFO - содержит сами атрибуты
USERS_TYPE - описание что это за атрибуты, и как их интерпритировать
вы раз это напишете, а в дальнейшем можно изменять типы пользователей и их атрибуты как угодно.
да, будет много пустых полей, не думаю, что база прям сильно вырастет и будет сильно напрягаться, джойниться всёравно будет по индексированному полю user_id. в веб форумах ваще, одна мега таблица с пользователями.. и ничё, работает.
я, таким образом, на одном сайте "универсальную базу" сделал... две таблицы, и хранить можно чё угодно, и списки документов, и перечень предприятий, и телефоны.