Блог

Главная - Вопросы по программированию - Дизайн базы данных: пользователь с контактной информацией

Дизайн базы данных: пользователь с контактной информацией

#database #database-design

#База данных #база данных-дизайн

Вопрос:

У меня есть вопрос по дизайну базы данных.

В моем приложении у пользователя есть контактная информация, включающая

  • номер телефона
  • Адрес электронной почты
  • адресная строка 1
  • почтовый ящик
  • Населенный пункт (город)

В настоящее время это находится в таблице «user» вместе с другой информацией, такой как имя пользователя, first name, …

Дело в том, что пользователь должен иметь информацию того же типа (телефон, электронная почта, …), но для своей компании.

Кажется излишним добавлять дополнительные поля в таблицу «пользователь». Поскольку данные похожи, я мог бы создать таблицу «ContactInfo» с полями:

  • телефон
  • Адрес электронной почты
  • адрес
  • почтовый ящик
  • …

Хорошая ли это идея и как мне следует установить связь между таблицей «user» и этой таблицей «ContactInfo»?

РЕДАКТИРОВАТЬ: я забыл сказать, что контактная информация компании не является обязательной. У пользователя может вообще не быть компании.

Ответ №1:

Все, что имеет отношение 1: M между пользователями, должно быть в отдельной таблице. Если вас интересует только основная контактная информация пользователя, то вам может сойти с рук сохранение ее в таблице User.

Например: если допустимо иметь два телефонных номера (или более), то у вас будет другая таблица с внешним ключом к вашей таблице users и номером телефона, типом телефона и приоритетом заказа контактов.

Ответ №2:

Отдельные таблицы — правильный выбор.

 CREATE TABLE users (
  id INT UNSIGNED NOT NULL,
  foo VARCHAR(50),
  PRIMARY KEY (id) );

CREATE TABLE user_contact_info (
  id INT UNSIGNED NOT NULL,
  user_id INT UNSIGNED NOT NULL,
  contact_type VARCHAR(40) NOT NULL,
  phone VARCHAR(20),
  email VARCHAR(200),
  address VARCHAR(200),
  postal_box VARCHAR(20),
  PRIMARY KEY (id, user_id) );

Если ваша база данных поддерживает внешние ключи, должен быть внешний ключ от user_contact_info.user_id до users.id . user_contact_info.contact_type было бы установлено значение work или home или любые другие категории, которые вам нужны.

Комментарии:

1. Это на самом деле то, что я хотел сделать. Кажется, это правильный выбор

2. Единственное, что с этим связано, — это дополнительная информация о работе. Интересно, что делать, когда пользователь удаляет информацию о своей компании. Тогда строка в user_contact_info была бы пустой.

3. Вы хотите сказать, что хотите отслеживать контактную информацию компании? Если это так, просто добавьте companies таблицу. Если у компании может быть более одного телефона, адреса и т.д., создайте company_contact_info таблицу, подобную user_contact_info приведенной выше таблице. Если вы хотите связать user с company , создайте user_company таблицу, которая поддерживает связь «многие ко многим» (с индикатором типа связи: employee , customer , оба?).

4. @Marc, если пользователь удаляет информацию о своей компании, удалите соответствующую строку в user_contact_info . Она не будет пустой, она исчезнет.

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

Ответ №3:

У вас должна быть отдельная таблица телефонов, отдельная таблица электронной почты и отдельная таблица адресов. У людей есть более одного из всех трех.