Проектирование баз данных. Связи между профилями?

Question

[Uglik]

Здравствуйте.

Вопрос по проектированию баз данных. Как бы вы проектировал базы данных в примере описанном ниже и организовали связь между ними.

Имеется профиль Парикмахера и Клиента. Как я понимаю создается таблица USERS где хранятся данные для авторизации (id, login, email, password, usergroup) и имеется 2 профиля, общее в них только (аватарка, и ФИО).

Профиль Парикмахера: хранит в себе данные (ФИО, аватарка, город проживания [отдельная таблица в городами по связи один ко многим], стрижки [отдельная таблица с названиями стрижек], цены, контакты [отдельная таблица с контактами {городской телефон, мобильный телефон, skype и тд}], о себе , портфолио[отдельная таблица с фотографиями], отзывы [отдельная таблица с отзывами по каждому парикмахеру]) и связь с таблицей предварительной записи (дата время и место).
Профиль клиента: хранит в себе данные ФИО и аватарка и связь с таблицей предварительной брони парикмахера на определенную дату и время.

Интересует как быть с профилями? Как бы вы в данной ситуации спроектировали данную связь? Создали бы 2 таблицы профилей, одну для клиента другую для парикмахера и сохраняли бы для каждого свои данные или все совместил бы в одну?

Еще момент по поводу расширения. Например если в будущем добавить визажиста и у него как я предполагаю будет свой профиль со своей информацией.

Как грамотно и правильно спроектировать данную задачу и связать таблицу юзеров с профилями клиента и парикмахера или визажиста?

Answer 1

[Андрей]

разные таблицы

Comments

[Uglik]

А как тогда индифицировать профили и организовать связи. Что бы индификаторы не повторялись

[Андрей]

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

[Uglik]

Андрей: Если вам не сложно не могли бы выслать пример. Буду очень благодарен.

Answer 2

[Станислав Макаров]

martinfowler.com/eaaCatalog/classTableInheritance.html

Answer 3

[Петр]

А что клиент не может быть парихмахером? Поэтому отдельная таблица профилей людей обязательна. (ФИО, адреса, аватарки)
А далее таблица парикмахеров в которой ссылка на человека, а далее специфичные данные парикмахера.

Comments

[Uglik]

Нет клиент может только сделать записать на стрижку и выбрать парикмахера из предложенного списка. Буду благодарен за пример.

Answer 4

[Алексей Лебедев]

Одна таблица, разница не существенна, будет парочка пустых полей и все.

Answer 5

[Uglik]

Еще больше запутался. Так одну таблицу профилей делать или 2?

Вариант первый:
Пользователи:

CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `username` varchar(255) NOT NULL COMMENT 'Имя пользователя',
  `email` varchar(255) NOT NULL COMMENT 'Электропочта',
  `password` varchar(255) NOT NULL COMMENT 'Пароль',
   PRIMARY KEY (`id`)
)

Группы пользователей:

CREATE TABLE `groups` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `name` varchar(255) NOT NULL COMMENT 'Имя группы пользователей',
   PRIMARY KEY (`id`)
)

Наборы групп, в которую входит каждый пользователь

CREATE TABLE `usergroups` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `user_id` int(11) NOT NULL COMMENT 'ID пользователя',
  `group_id` int(11) NOT NULL COMMENT 'ID группы пользователей',
   PRIMARY KEY (`id`)
)

И одна таблица с профилями:

CREATE TABLE `profile` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `avatar` varchar(255) NOT NULL COMMENT 'Аватарка',
  `firstname` varchar(255) NOT NULL COMMENT 'Имя пользователя',
  `lastname` varchar(255) NOT NULL COMMENT 'Фамилия пользователя',
  `about` text COMMENT 'О себе',
  `location_id` int(11) NOT NULL COMMENT 'Индификатор города',
  `haircut_id` int(11) NOT NULL COMMENT 'Индификатор стрижки',
  `price` decimal(10,2) NOT NULL COMMENT 'Индификатор стрижки',
  `contacts_id` int(11) NOT NULL COMMENT 'Индификатор контакта',
  `portfolio_id` int(11) NOT NULL COMMENT 'Индификатор портфолио',
  `reviews_id` int(11) NOT NULL COMMENT 'Индификатор отзыва',
   PRIMARY KEY (`id`)
)

В таком случае будет много полей пустых, но многие поля NOT NULL с индикаторами других таблиц с данными. Как в данной ситуации быть.

Вариант второй:

Тоже самое только 2 таблицы профилей:

Парикмахеры

CREATE TABLE `profile_hairdresser` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `user_id` int(11) NOT NULL COMMENT 'Номер записи',
  `avatar` varchar(255) NOT NULL COMMENT 'Аватарка',
  `firstname` varchar(255) NOT NULL COMMENT 'Имя пользователя',
  `lastname` varchar(255) NOT NULL COMMENT 'Фамилия пользователя',
  `about` text COMMENT 'О себе',
  `location_id` int(11) NOT NULL COMMENT 'Индификатор города',
  `haircut_id` int(11) NOT NULL COMMENT 'Индификатор стрижки',
  `price` decimal(10,2) NOT NULL COMMENT 'Индификатор стрижки',
  `contacts_id` int(11) NOT NULL COMMENT 'Индификатор контакта',
  `portfolio_id` int(11) NOT NULL COMMENT 'Индификатор портфолио',
  `reviews_id` int(11) NOT NULL COMMENT 'Индификатор отзыва',
   PRIMARY KEY (`id`)
)

Клиенты

CREATE TABLE `profile_client` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `user_id` int(11) NOT NULL COMMENT 'Номер записи',
  `avatar` varchar(255) NOT NULL COMMENT 'Аватарка',
  `firstname` varchar(255) NOT NULL COMMENT 'Имя пользователя',
  `lastname` varchar(255) NOT NULL COMMENT 'Фамилия пользователя',
   PRIMARY KEY (`id`)
)

В данной ситуации я тогда не понимаю как связать профили с юзерами через связь многие ко многим. Если не сложно вышлите пример.

Промежуточная таблица получаеться типа:

CREATE TABLE `profile_client_hairdresser` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Номер записи',
  `user_id` int(11) NOT NULL COMMENT 'ID пользователя',
  `profile_id` int(11) NOT NULL COMMENT 'ID профиля пользователей',
   PRIMARY KEY (`id`)
)

НО профиля у нас 2!

Comments

[Петр]

Если делаешь основной информацию по парикмахерам, то и создай таблицу
"Парикмахер" (ID, userid, ФИО, адресс, аватар и т.п.) это будет справочник. А для пользователей сайта "Пользователи" (id, email, контактное имя, password). Этого будет достаточно. Кто будет записываться "Запись" (id, userid, парикмахер id, время, тип стрижки, phone, салон-id, note)

[Uglik]

Петр: а если сделать вот так: основная таблица users (id, username, email (в качестве логина), password, usergroup (1 - парикмахер, 2 - клиент) ) и 2 таблицы профилей prifile_photog (id, user_id, avatar, firstname, lastname, стрижки, price и тд) и profile_client (id, user_id, avatar, firstname, lastname) вдруг в будущем придется расширить таблицу клиентов.

Юзер проходит авторизацию и мы делаем проверку если он относиться к первой группе выводим ему профиль парикмахера, если ко второй клиента.

В данном случае мы видим что 2 таблицы профилей содержат одинаковые столицы (avatar, firstname, lastname) которые в принципе можно вынести в основную таблицу users, но в данном случае таблицу клиентов сложно будет расширять дальше.

Реализовать очень простую форму регистрации (login и password). Получается клиент проходит форму регистрации и попадает в свой пустой профиль, который ему нужно заполнить (Указать ФИО и загрузить аватарку)

Суть заключается в том, как же поступить. Создать 3 таблицы или все же обойтись 2. И хранить в USERS (id, avatar, firstname, lastname, email, password), но аватарку на стадии регистрации грузить будет странно)

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

[Петр]

Uglik: users [usergroup] точно лишнее, т.к. пользователь может входить в 2 группы. И зачем вам хранить фамилию и имя клиента? Для записи на стрижку это не нужно.

[Uglik]

Петр: "users [usergroup] точно лишнее, т.к. пользователь может входить в 2 группы." А как по другому разделить пользователей в таблице users и понять кто есть кто ? Если пользователь входит в 2 группы можно создать связь многие ко многим как я описал выше и присваивать индикаторы групп к каждому пользователю. Да и вообще можно сделать тупо один user один профиль

[Петр]

Uglik: А их не нужно тут делить. users это пользователи сайта. Логин/емайл, пароль, никнейм достаточно. И у вас парикмахеры не обязательно будут пользователями сайта.

[Uglik]

Петр: а если на сайт добавить новые группу визажисты, стилисты, маникюр, педикюр и все такое

[Петр]

Uglik: Так ведь это справочная информация, она отвязана от users.

[Петр]

Uglik: Представьте, что вы делаете два простых сайта. На одном регистрация пользователей по простому, а на втором справочная информация по парикмахерам и визажистам и т.д. Когда будут готовы структуры данных для этих сайтов, то поробуйте обьединить данные. И все получится как надо.

[Uglik]

Петр: ну с этой стороны да, если добавить новую группу например визажиста появиться новая таблица и у нее будет user_id по которому можно будет отсортировать пользователей, в общем ход мыслей понятен.

Но с другой стороны пользователь заходит на сайт и нажимает регистрацию и ему предлагает 2 варианта парикмахер и клиент

[Uglik]

Петр: нужно же скрипту понять кто есть кто и чего ему дальше выводить профиль парикмахера или клиентскую часть

[Петр]

Uglik: Зачем новые таблицы плодить. Объединяйте все, что можно обьединить. А уж что нельзя, тогда в отдельную. Скрипт и не должен понимать, вы как программист должны понимать как их разделить.