Модель базы данных SQL для контактных данных

Question

Мне нужна база данных для хранения, то есть записи пользователя. Обычные вещи: имя, электронная почта, адрес, телефон, факс и так далее. Проблема в том, что в этом случае может быть более одного номера телефона на пользователя. И более одного электронного письма. Даже более одного адреса. И многое другое.

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

Еще одна - индивидуальная таблица для телефонов, индивидуальная таблица для адресов и так далее. Столбцы: id , customer_id , phone . customer_id ссылки клиенты . id Теперь это похоже на реальное излишество, имея около 10 таблиц только для хранения контактных данных.

И еще одна идея, которую я выдвинул, - это одна дополнительная таблица для контактов со столбцами, такими как id , customer_id (<-foreign key), <strong>key , значение . Где ключ может быть «телефон» и значение «+123 3435454», или ключ «электронная почта» и значение ... у вас есть идея. Пока что мне больше всего нравится этот.

Что бы вы предложили? Каковы недостатки системы # 3?

db Я собираюсь использовать это postgresql , но это не имеет значения.

Answer 1

Кто-то может сказать, что метод № 3 самый лучший. Другие скажут, что это в основном один из самых распространенных анти-паттернов в базах данных, а именно EAV , который очень ненавидит.

Что касается меня, я слишком мало знаю о вашем заявлении, чтобы предложить решение. Как правило, метод № 2 дает вам наибольшую функциональность.

Существует также метод № 4 и его вариант - метод № 5:

4 - использовать массивы значений - то есть телефонный столбец, а не база данных TEXT, это TEXT [], и тогда вы можете хранить в нем много телефонов.

5 - поскольку вы используете PostgreSQL - используйте его. В contrib есть довольно крутой тип данных hstore, который вы можете использовать вместо массивов для добавления некоторой семантики (например, типа телефона).

Answer 2

Одна строка таблицы на одну сущность верна. Так что один для электронной почты, один для телефонных номеров и т. Д. Является правильным. это не излишество: это нормализованный дизайн базы данных.

Ваш вариант 3 может быть выполнен, но, скажем, что, если вы хотите применить определенный шаблон для телефонных номеров и адресов электронной почты?

Answer 3

Некоторые пуристы считают, что нет 3, чтобы идти. Фактически, используя этот подход, вы теоретически могли бы создать базу данных из одной таблицы!

Однако, как упоминалось в gbn, это может вызвать проблемы с конкретными форматами, и вам придется принудительно устанавливать длины данных и т. Д. Только на клиенте.

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

идентификационный номер addrss_type varchar (home / contact / mail и т. д.) addrs_line1 varchar addrs_line2 varchar и т. д.

Answer 4

Downsides:

1. Это нарушает первую нормальную форму, так как у вас будет много значений для одного поля
2. Как вы сказали, это было бы кошмаром для поддержания

3. Кажется, что опция ставок, но может быть нормализована с использованием таблицы доменов для этого значения «ключа»

   • Customer (Id, Name)
   • AdditionalData( Id, Name ) (телефон, адрес и т. Д.)
   • CustomerAdditionalData(Id, CustomerId, AdditionalDataId, Value)