Дизайн базы данных - Как мне установить отношение FK к 1 из 2 таблиц?

Question

Каков наилучший способ сохранить поле уникального идентификатора в нескольких таблицах базы данных?

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

Вот некоторые идеи, о которых я думаю:

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

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

• Объедините людей и компании в одну таблицу.Моя проблема в том, что люди и компании имеют разные свойства и нуждаются в отдельных полях, и это противоречит моей природе, так как я предпочитаю иметь отдельные таблицы для отдельных сущностей.

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

• Какой-то лучший способ справиться с этим, о котором я не знаю, так как я не являюсь dba

Какое бы решение я ни использовал, оно должно иметь возможность легко обрабатывать большое количество записей (база данных, которую он собирается заменить, содержит несколько миллионов записей) и находится на MS Sql Server

Answer 1

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

Я бы сделал одно из следующих действий:

Конечно, вы можете использовать два отдельных столбца в таблице адресов для каждого из двух объектов. BusinessId и peopleid. ФК могут иметь нулевые значения, так что все будет в порядке. И тогда вы можете принудительно установить отношения FK, что избавит вас от проблем с целостностью данных.

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

или настройте отдельные дочерние таблицы - служебный, а затем служебный адрес, адрес людей и людей и т. Д. Тогда вам не нужно сохранять идентификаторы уникальными между двумя логическими объектами.

Я забыл об одной возможности: если у вас много-много связей, у вас могут быть Адрес, Бизнес, Люди, а затем несколько таблиц связи, BusinessAddress, PeopleAddress. Лично я бы не использовал GUID, если бы у меня был другой выбор, так как они могут повредить производительности

Answer 2

Вы также можете изменить свое мышление.

Вместо того, чтобы у Address был идентификатор человека или компании, у человека или компании есть идентификатор адреса.

Это более естественный способ думать об этом в моей книге ... Человек имеет адрес.

Answer 3

Создайте таблицу «supertype», которая идентифицирует как предприятия, так и людей, и свяжите эту таблицу с вашим внешним ключом. Это общий шаблон для ситуации. См .: Модель данных партии .

Answer 4

Некоторые базы данных позволяют иметь внешние ключи с нулевыми значениями.Некоторые нет, и я не могу вспомнить, если SQL Server делает.Если ваш позволяет, вы можете иметь 2 столбца идентификатора в таблице адресов, один из которых указывает на людей, а другой - на предприятия.Этот подход также имеет свои плюсы и минусы;Одним из недостатков является то, что он, вероятно, недоволен вашим администратором базы данных, но если ваша база данных это позволяет, возможно, это может быть одной из альтернатив.

Answer 5

Существует несколько различных шаблонов для этого, но самый простой и гибкий - использовать уникальные идентификаторы (GUID);большинство БД имеют некоторые средства для их создания (например, SQL Server - это NEWID ()).Они больше, чем другие формы удостоверения личности, но они сделают ту работу, которую вы ищете.

Answer 6

Для этого нужны GUID.

Answer 7

Businessess и люди действительно полностью отделены от бизнеса?

У них нет ничего общего, даже не "дня, когда они родились"?

Бизнес не рассматривает их обоих как "контрагентов"?

То, что я пытаюсь проиллюстрировать, заключается в том, что вы достаточно пристально смотрите на бизнес, без обычно ослепляющих очков, через которые обычно смотрит средний ИТ (так называемый) «профессионал», тогда вы очень быстро найдете общие черты Вы ищете.

Определите таблицу в вашей базе данных, чтобы записать эти общие черты (ДАЖЕ, если это не что иное, как идентификация), и сделайте адреса, ссылающиеся на ЭТ таблицу.

Answer 8

GUID хороши в качестве уникальных идентификаторов, ничего больше.
Проблема с GUID заключается в их размере, особенно если ваша БД будет огромной.
Они не должны использоваться в соединениях (индекс, внешний ключ,...).
У нас был точный дизайн БД, который мы должны были изменить на Integer, когда число записей стало слишком большим.
Я также хотел бы отметить, что вы должны быть осторожны с вашим дизайном для вашеголица / предприятие / адрес.Это отношение многих ко многим.Предприятие / человек может иметь более 1 адреса, адрес может быть для нескольких предприятий / лиц ...

Если вы хотите разделить предприятия и людей, вы можете иметь 2 таблицы PersonAddress и BusinessAddress для хранения отношений и вам придется объединиться при поиске адреса для обоих , или вы можете иметь одну таблицу EntityAddress дляоба предприятия - Лица вместе с полем EntityNature , указывающим, является ли это бизнес или частное лицо.