Если один объединить внешние ключи, которые указывают на ту же таблицу, если требуются все столбцы?

голоса
0

Я сталкиваюсь с этой ситуацией часто. Пример,

userОднозначно идентифицируется appId, externalUserId.

Таблица xxxContractимеет внешний ключ (fileUploadId, appId, externalUserId)к таблице , fileUploadкоторая обеспечивает загрузку файла принадлежит указанному пользователю.

Таблица xxxContractимеет внешний ключ (businessId, appId, externalUserId)к таблице , businessкоторая обеспечивает бизнес принадлежит указанному пользователю.

С учетом указанных выше двух, мы гарантируем загрузки файлов пользователь А не будет использоваться в качестве контракта для бизнес-пользователей, Б.


xxxContractтакже есть fileTypeIdстолбец , который STORED GENERATEDдо определенного значения , которое говорит : «Этот контракт типа файла XXX_CONTRACT»

Таблица xxxContractтакже имеет внешний ключ (fileUploadId, fileTypeId)к таблице fileUpload.

Это гарантирует , мы используем только XXX_CONTRACTзагрузки файлов xxxContract, а не случайно использовать другие типы файлов.


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

  • (fileUploadId, appId, externalUserId)
  • (fileUploadId, fileTypeId)

И все столбцы NOT NULL.

Так, мне кажется, что это безопасно объединить внешние ключи в одну большую внешнего ключа,

(fileUploadId, appId, externalUserId, fileTypeId)

И мы по-прежнему имеем ту же гарантию, как и раньше.


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

Но я никогда не имел формальное образование с этими вещами, так что я хотел бы знать, что стандарт промышленности.

Связанные, есть ли выигрыш в производительности, чтобы объединить их против разделения их?

Задан 07/11/2018 в 20:11
источник пользователем
На других языках...                            


1 ответов

голоса
0

Но я никогда не имел формальное образование с этими вещами, так что я хотел бы знать, что стандарт промышленности.

Стандарт, что не существует никакого стандарта.

Как уже отмечалось, можно использовать несколько столбцов , чтобы определить первичный ключ. Это называется естественным первичным ключом , например: пользователь может быть однозначно определен ПгвЬЫатом, LastName - и дата рождения. (по крайней мере , почти никогда)

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

Косвенные (или искуственные) первичные ключи также хорошо известны: idстолбец, используя автоматическое приращение.

Таким образом, как на ваш вопрос: Да, если у вас есть 3 колонки, которые уже образуют естественный первичный ключ, то укомплектовать безопасно добавить несколько столбцов. С 3-х колонок, уже присутствующих будет однозначно идентифицировать строку, нет никакого вреда в добавлении 4-й, 5-й или 6-й столбец даже к ключу.

Если вы собираетесь использовать природные или суррогатные первичные ключи depens от личных предпочтений я бы сказал. Я никогда не использую природные ключи, даже на столах, где это возможно.

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

С точки зрения производительности, я предполагаю, что (Integer основе) суррогатные первичные ключи, как правило, быстрее, чем (String основе) естественных первичных ключей. Это даже меньше столбцов следует учитывать при написании запросов и / или разработки индексов.

Ответил 07/11/2018 в 21:57
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more