Составной первичный ключ

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

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

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

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

Единственный вопрос - добавляете ли вы дополнительный столбец и отмечаете его УНИКАЛЬНЫЙ . Единственная причина, по которой я могу это сделать, - это производительность, что является законной причиной.

Лично мне не нравится подход, когда каждая база данных превращается по сути в граф, где сгенерированные столбцы по сути являются указателями, а вы просто переходя от одного к другому. Я думаю, что это отбрасывает все величие системы отношений. Если вы отступите и подумаете об этом, вы вводите кучу столбцов, которые вообще не имеют никакого значения для вашего бизнеса. Возможно, вас заинтересует мой сообщение в блоге .

Я считаю, что составные ключи создают очень естественную и описательную модель данных. Мой опыт исходит из Oracle, и я не думаю, что при создании составного ПК возникают какие-либо технические проблемы. Фактически, любой, кто проанализирует словарь данных, сразу кое-что поймет о таблице. В вашем случае было бы очевидно, что каждый source_id должен иметь уникальный id_on_source.

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

Практически единственный раз, когда я использую составной первичный ключ, - это когда старшая часть ключа является ключом к другой таблице. Например, я мог бы создать таблицу OrderLineItem с первичным ключом OrderId + LineNumber. Поскольку многие обращения к таблице OrderLineItem будут «заказывать соединение orderlineitem с использованием (orderid)» или некоторым его вариантом, это часто бывает удобно. Это также упрощает при просмотре дампа базы данных, чтобы выяснить, какие элементы строки связаны с каким порядком.

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

Двухкомпонентные ключи - это неплохо; Я делаю это довольно часто. Я не хочу использовать ключ из трех частей. Более чем из трех частей, Я бы сказал, забудьте об этом.

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

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

Хотя uniqueid является хорошим первичным ключом, я согласен, что обычно лучше использовать другой, естественный ( не обязательно уникальный) ключ в качестве кластерного индекса. Например, если uniqueid - это PK, который идентифицирует сотрудников, вы можете захотеть, чтобы кластерный индекс был отделом (если ваши операторы выбора обычно извлекают всех сотрудников в данном отделе). Если вы хотите использовать unqiqueid в качестве кластеризованного индекса,

Добавление дополнительного столбца идентификатора приведет к тому, что вам придется применять ДВА ограничения уникальности вместо одного.

Использование этого дополнительного столбца идентификатора в качестве внешнего ключа в других ссылочных таблицах вместо ключа, который возникает естественным образом, заставит вас делать БОЛЬШЕ объединений, а именно во всех случаях, когда вам нужен исходный soruce_ID плюс ID_on_source вместе с данными из ссылающейся таблицы.