Отношения SQL

Question

Я использую MS SQL Server 2008R2, но я считаю, что это не зависит от базы данных.

Я переделываю часть своей структуры sql и ищу лучший способ установить отношения 1 ко многим.

У меня есть 3 таблицы, Компании, Поставщики и Утилиты, любая из которых может иметь отношение 1 ко многим с другой таблицей под названием VanInfo.

Информация о фургоне может принадлежать компании, поставщику или коммунальному предприятию.

Первоначально в таблице VanInfo у меня был company_id, который указывал на таблицу company, но затем, когда я добавлял поставщиков, им также потребовались записи vaninfo, поэтому я добавил еще один столбец в VanInfo для supplier_id и установил ограничениечто был установлен либо supplier_id, либо company_id, а другой был нулевым.

Теперь я добавил утилиты, и теперь им нужен доступ к таблице VanInfo, и я понимаю, что это не оптимальная структура.

Каков был бы правильный способ установить эти отношения?Или мне просто продолжить добавление внешних ключей в таблицу VanInfo?или создать какую-то таблицу перекрестных ссылок.

Технически приложение еще не запущено, но я хочу убедиться, что оно настроено с использованием наилучших возможных практик.

ОБНОВЛЕНИЕ: Спасибо за все быстрые ответы.

Я прочитал все предложения, проверил все ссылки.Моим основным критерием является то, что было бы легко изменить и поддерживать, поскольку требования клиентов всегда имеют тенденцию меняться без особого уведомления.После изучения, исследования и планирования, я думаю, что лучше пойти с таблицей перекрестных ссылок с названием «Организации» и отношениями «1: 1» между компаниями / коммунальными предприятиями / поставщиками и таблицей организаций, что позволяет четко установить связь с таблицей Vaninfo.,Это будет легко поддерживать и по-прежнему правильно моделировать мои бизнес-объекты.

Answer 1

В вашем примере я бы всегда использовал «некую таблицу перекрестных ссылок» - добавляя столбцы в запахи таблицы VanInfo.

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

Answer 2

Рассмотрите возможность создания Com, Sup и Util PKs GUID, этого должно быть достаточно для решения проблемы. Однако это соответствие может быть хорошим индикатором плохого дизайна базы данных, но чтобы предложить другое решение, нужно знать более широкий контекст базы данных, то есть то, что вы пытаетесь достичь. Мне кажется, что VanInfo должен быть просто отдельной сущностью для каждой из таблиц (да, точный дубликат, такой как Com_VanInfo, Sup_VanInfo и т. Д.), Если VanInfo не разделяется между этими сущностями (тогда отношения должны быть перевернутый, то есть Com, Sup и Util должны содержать FK для VanInfo).

Answer 3

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

http://en.wikipedia.org/wiki/Fifth_normal_form

Вы также можете увидеть это, нормализация базы данных:

http://en.wikipedia.org/wiki/Database_normalization

Answer 4

Когда вы разрабатываете базу данных, вы не должны думать о том, куда идет первичный / внешний ключ, потому что это понятия, которые не относятся к стадии проектирования. Я знаю, это звучит странно, но вы не должны думать и о столах! (вы можете реализовать свою модель E / R, используя XML / Files / Wh независимо Придерживаясь дизайна отношений E / R, вы должны просто определить свою сущность (в вашем случае Company / supplier / utilities / vanInfo), а затем подумать о том, какие отношения существуют между ними (если они есть). Например, вы сказали, что у компании может быть один или несколько VanInfo, но информация о Van может принадлежать только одной компании. Мы говорим об отношениях один ко многим, как вы уже догадались. На этом этапе, когда вы «конвертируете» свою модель проектирования (отношение «один ко многим») в таблицу базы данных, вы будете знать, куда поместить ключи / внешние ключи. В случае отношения «один ко многим» внешний ключ должен переходить в сторону «многие». В этом случае информация о фургоне будет иметь внешние ключи к компании (поэтому таблица vaninfo будет содержать идентификатор компании). Вы должны следовать этим путем для всех остальных таблиц

Посмотрите на ссылку ниже:

https://homepages.westminster.org.uk/it_new/BTEC%20Development/Advanced/Advanced%20Data%20Handling/ERdiagrams/build.htm