Какой внешний ключ использовать в таблице «многие к одному»

Question

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

У меня есть другая таблица Sales с первичным ключом Sale_ID,внешний ключ для ссылки на книги и другие поля с информацией о продажах.Продажи существуют только для книг с номерами ISBN.Является ли лучше дизайн базы данных, чтобы Book_ID или ISBN были первичным ключом.Примечание. Я ЛЕВО ПРИСОЕДИНЯюсь к отделу продаж книгам в зависимости от того, какой внешний ключ выбран.

ОБНОВЛЕНИЕ: в некоторых книгах нет номеров ISBN, поскольку они не публикуются вместе с ними.Однако я не предполагаю (по крайней мере, в ближайшие несколько лет), что пользователи смогут продавать их, потому что у меня нет системы, которая бы обеспечивала повторение данной книги без ISBN.

Answer 1

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

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

• Возможно, у вас отсутствует или неизвестно ISBN для конкретной книги. Что бы вы сделали в случае продажи этой книги?
• Возможно, вы неправильно указали ISBN. Чтобы отредактировать его, вам необходимо обновить все таблицы, которые будут использовать его в качестве внешнего ключа.
• Возможно, вы захотите начать продавать книги, у которых нет ISBN в будущем. Почему вы храните книги без ISBN?
• Индекс на book_id должен быть намного более компактным, чем индекс на ISBN поле.

Answer 2

Я бы всегда использовал ISBN.Таким образом, у вас есть простой способ применения вашего бизнес-правила: «Продажи существуют только для книг с номерами ISBN», т. Е. Путем создания столбца ISBN NOT NULL в таблице Sales и ссылки на столбец ISBN в * 1006.* table.

Я не согласен с @Daniel Vassallo, что, поскольку вы, возможно, захотите начать продавать книги, у которых нет ISBN , в будущем , вы захотите отказаться от правилав базе данных сегодня.У этого изъяна в дизайне есть имя: будущая крипия.Кроме того, соображения о «компактных индексах» всегда должны быть вторичными по отношению к базовым показателям целостности данных.

Answer 3

Я бы всегда использовал ваш первичный ключ