Отношение один ко многим, связанное со многими таблицами

Question

У меня есть сценарий, где: Есть две (или более) таблицы, которые представляют независимые элементы. скажем, пользователи и компании

Обе эти таблицы нуждаются в сохранении адресов. Каждый из них может иметь один или несколько адресов

В обычном сценарии «Адреса 1 ко многим» у таблицы woudl просто есть UserId или CompanyId, создающие нормальное отношение «1 ко многим».

В этом случае у меня есть несколько подходов, которые я могу придумать

1. таблица адресов может иметь как UserId, так и CompanyId, и для каждой записи будет использоваться только один.

2. Можно использовать 2 ключа ObjectId и ObjectType, поэтому у Object ID будет UserId или CompanyId, а ObjectType будет User или Company

3. Создайте ObjectTable и добавьте ObjectId для пользователей и компаний. Адреса тогда будут иметь OjbectId

Мне не очень нравится ни одно из этих решений. мне интересно, каков наилучший подход здесь.

В другой заметке я, скорее всего, буду использовать linqtosql для своего уровня доступа к данным.

Answer 1

Я не уверен насчет последствий, связанных с Linq-to-SQL, но одной из моделей для решения этой проблемы является использование нескольких Junction Tables .

В вашем случае у вас будет таблица AddressUsers с двумя столбцами: AddressId и UserID и таблица AddressCompanies с столбцами AddressId и CompanyId.

Answer 2

Я рекомендую следовать советам tpdi, но использовать отношение один-ко-многим между пользователями / компаниями и адресами;по крайней мере, тогда все ваши ключевые типы данных будут одинаковыми.

Основная причина добавления моего ответа в ответ на ваше второе предложение о сохранении ObjectID и ObjectType - разделение атрибутов - плохая идея, избегайте!

Прочитайте этот пост Celko: http://www.tdan.com/view-featured-columns/9852

Answer 3

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

В стандартной практике полиморфная ассоциация обычно может быть преодолена путем ее изменения. Вы должны пойти с одной таблицей пересечений (соединений) для каждого пользователя и компании, чтобы присоединить их к адресу. Это похоже на отношение «многие ко многим», где каждая строка в таблице пересечений ссылается на одного пользователя и один адрес.

Если вы используете таблицы пересечений, во избежание «многие ко многим» (но сохраняйте «один ко многим») накладывайте уникальное ограничение на адресный ключ в таблицах пересечений.

Если у вас возникают проблемы с ORM, используйте родительскую таблицу адресов, которая соединяется с UserAddress и CompanyAddress.

Answer 4

Переходи ко-многим:

Таблица адресов с уникальным синтетическим идентификатором (например, автоинкремент).

Таблица user_address с уникальным синтетическим идентификатором (например, автоинкрементом), внешним ключом user_id и внешним ключом адреса.

Таблица адресов компании, с уникальным синтетическим идентификатором (например, автоинкрементом), внешним ключом company_id и внешним ключом адреса.

(Обратите внимание, что если пользователи (или компании) могут иметь только один адрес, у вас просто есть внешний ключ address_id в таблице пользователей (или в таблице компании). Это не ваш вариант использования.)