Можно ли установить составной ключ в качестве первичного ключа в другую таблицу?

Question

Может ли составной ключ быть установлен в качестве первичного ключа к другой таблице?

Например у меня есть таблицы:

• Books -с Первичный ключ: Product_ID
• Client -с Первичный ключ: Client_ID
• Clients_Books -с Соединение Первичный ключ: Product_Id и Client_ID

Я хочу установить это соединение Первичный ключ для m Clients_Books как первичный ключ к другой таблице с именем: Order_Details. Но я не хочу использовать Product_ID и Client_ID из таблиц Books, Clients.

Имеет ли это смысл? Все мнения более чем приветствуются.

Answer 1

Короткий ответ: Нет - не может этого сделать. Все столбцы в PK (или другом альтернативном ключе) должны отображаться в определении FK. Также помните, что таблица может иметь несколько ключей, называемых ключами-кандидатами (иногда альтернативными клавишами). Первичный ключ - это просто «лучший» ключ для вашего дизайна/использования (обычно самый узкий - наименьший по размеру байта). Мы назначаем имя этих других уникальных индексов как «AK_ {name}» - AK = Alternate Key.

Что мы делаем под этим обстоятельством является одна из двух вещей:

1. определяют синтезированный PK быть столбец «Идентичность», а затем добавить индекс уникальный для ключа соединения - таким образом, имеющих два «ключи» на столе. Затем все дочерние таблицы определяют FK как указывающий на синтетический столбец Identity PK.
2. Оставьте составной ключ как есть. Определите его как PK на этой главной таблице и сделайте все FK одинаковым.

Как правило, не рекомендуется иметь несколько таблиц с одним и тем же определением PK (то есть PK, которые также являются FKs для другой таблицы). Я говорю «в целом» - важно понимать определение ваших Существ.

Так зачем использовать # 1? Вопрос, который я задаю себе, заключается в том, является ли составной ключ действительно данными, определяющими строку? Является ли этот составной ключ действительно определением строки или это скорее FK для некоторых других данных? Если это больше FK, я создаю синтезированный PK (Identity). Является ли заказ действительно книгами, которыми владеет клиент? Заказ может привести к тому, что клиент получит новую книгу - но это может быть не одно и то же.

Наличие синтетических ПК предлагает еще несколько вариантов в будущем в будущем. Если в таблице Client_Books необходимо изменить отношения, вы можете изолировать изменения в других таблицах.

Например, что, если клиент может владеть более чем одной копией книги - как вы это реализуете? С помощью синтезированного ключа вы можете просто удалить индекс Unique из составного ключа и оставить его как простой FK, тогда таблица Order_Details будет просто представлять, когда клиент купил свою вторую копию.Если, однако, вы взяли составной ключ на маршруте Заказы, тогда вам нужно будет выяснить, как переопределить Order_Detail, а также Client_Books (и любые другие FK, указывающие на Order_Detail).

Я также прошу вас оценить, действительно ли Order_Detail является Client_Book? Обычно заказ приводит к тому, что клиент получает новую книгу. Я считаю, что Заказы не зависят от инвентаря, поэтому ПК на Order_Detail не должен быть PK на Client_Books, Order_Detail должен иметь собственный независимый PK.

Answer 2

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