Как моделировать таблицы с внешними ключами из нескольких других таблиц

Question

Я пытаюсь создать приложение для контактов, в котором есть две основные сущности - личность и компания. Человек может иметь много адресов электронной почты, номеров и адресов. Компания также может иметь много адресов электронной почты, номеров и адресов. Я пытаюсь определить правильный дизайн для этого сценария.

Опция № 1 - несколько внешних ключей
Электронные письма, номера и адреса будут иметь два столбца с именами person_id и company_id. В зависимости от того, к какому объекту принадлежат данные, один из них будет нулевым, а другой будет содержать идентификатор, ссылающийся на родителя.

Вариант № 2 - одна таблица для каждого типа на объект
Я дублирую каждую таблицу, чтобы была таблица company_addresses и таблица person_addresses. У меня было бы вдвое больше таблиц, но сейчас это решение имеет смысл.

Вариант № 3 - одна таблица ссылок
Я создаю одну таблицу - «ссылка». Эта таблица будет содержать четыре столбца: source_id, source_entity, dest_id, dest_entity. Поэтому, если компания получает новый номер, у вас будет такая строка: 1, номер, 2, компания.

Опция № 4 - таблицы с несколькими ссылками
Я создаю таблицу для каждого типа ссылки (company_address, person_address, company_email, person_email и т. Д.)

Какой вариант вы бы выбрали?

Answer 1

Вы затронули пару практик, я бы сказал, что вы избегаете. Я написал больше об этом в Ошибки разработки баз данных, сделанные AppDevelopers (например, эксклюзивные дуги).

Что касается вашей проблемы, я бы на самом деле не выбрал ни один из этих вариантов. То, к чему вы спотыкаетесь, - это общая модель партии . По сути, у вас есть объект Party с подтипами, такими как Персона и Организация. Контакты имеют идентификатор партии в качестве внешнего ключа. Использование общего суперкласса / суперспособности гораздо более глубокое, чем это, однако, поскольку вы обнаружите, что вы используете это и для многих других вещей (например, для всей концепции роли).

У многих из этих проблем моделирования проектирования баз данных есть зрелые решения, но программистам никогда не научат такому. Я настоятельно рекомендую получить книгу The Resource Book модели данных, Vol. 1: Библиотека универсальных моделей данных для всех предприятий , в которой более подробно рассказывается о том, как моделировать людей и организации, а также о многих других типичных проблемах.

Ключевой момент, который следует помнить, заключается в том, что то, что вы делаете, было сделано раньше.

Answer 2

Либо вариант № 2, либо я бы сделал это:

Вы можете создать EntityTable, который будет определять Id и тип Entity, тогда у вас будет ссылка на ваш адрес, таблицы электронной почты.

Затем вы создаете таблицу лиц и компаний, которая ссылается на сущность. Другими словами ваша сущность подкласса.

Вариант № 1 - Я использовал это в прошлом, и это может стать головной болью, когда все становится сложнее и растет.

Вариант № 3 - Вы не можете использовать ссылочную целостность, и затраты на сохранение нескольких нажатий клавиш для варианта № 2 не будут стоить очистки неверных данных или дополнительной сложности.