Проектирование базы данных. Вопрос о связи таблиц?

[Den1xxx]

Честно говоря, не особо понимаю несколько таблиц с пользователями...
Пустые колонки есть особо и не просят... Зато поиск облегчается...

А если человек и клиент, и фотограф? 2 учётки?

Делай в 1 таблице и не парься... Не популярные поля - выноси в text с json, популярные/большие - в отдельные колонки. Поменять - раз плюнуть.
Поля "не для всех" можно вынести в доп. таблицу и цеплять через LEFT (RIGHT) JOIN, как у DLE мета-данные к новостям.

Да, и 2, и 3 учётки возможны. В случае 3 таблиц облегчится поиск и вставка-удаление новых сущностей в будущем.
Это один из краеугольных принципов правильного проектирования БД — Для просмотра ссылки Войди или Зарегистрируйся.
Так следует поступать, когда БД проектируется под развитие.
Рекомендуется в Вашем случае использовать не менее чем вторую нормальную форму. Иначе Вы не сможете переименовать всех парикмахеров на стилистов, например.
Если же вебмастер не предполагает развития проекта — можно и в json сохранять. Появятся затраты процессорного времени при каждой выборке-вставке, усложнится поиск. Зато проект можно сдать Заказчику быстрее, а на последствия пох.

 

[lurkrz]

тут скорее вопрос не как, а для чего? для функиональности или для скорости? какие объемы данных планируются? минимальный вариант это в основной таблице создать 3 колонки, по колонке для каждой доп таблице и проставлять ИД от нужной. Но вообще структура проблемная получается

 

[Горбушка]

никогда нет выбора между фукциональностью и скоростью... Есть "Как сделать нужный функционал наиболее быстрым"... Если выбирать между функциональностью и скоростью - переводи сайт на хтмл и точка ))

 

[cheery.mae]

I Suggest creating just 2 tables (or possible just 1) to hasten everything in the query (just add all the column in the single table) then add a user group column. This helps you lessen the join, thus making it less CPU/Memory intensive. it may not be normalized but this is how big companies are doing it right now since Disk space is cheaper than CPU/RAM and making the queries very fast!