Требуется ли отдельная таблица базы данных, если она имеет отношение «многие ко многим» и имеет только один столбец?

Question

Скажем, у меня есть система, которая каталогизирует книги, и я хочу сгруппировать их по жанрам, и есть кортеж UNF:

BookId (PK): number
BookTitle: string
Blurb: string
Genres: string[]
(... everything else)

Когда нормализуется, нужно сделать Atom c жанра, а также должно быть помещено в его собственное отношение, чтобы не вызывать дублирования. Мой первый инстинкт - это сделать следующее:

BOOK
BookId (PK): number
BookTitle: string
Blurb: string

GENRE
GenreId (PK): number
GenreName: string

BOOKGENRE
BookId (CK): number
GenreId (CK): number

Но мне пришла в голову другая идея, но что-то было в ней ... неправильно (?) И, как будто это была плохая практика. Но моя идея состояла в том, чтобы избавиться от таблицы GENRE, просто сделав поле GenreName первичным ключом и используя только BOOKGENRE. Поскольку GenreName по-прежнему индексируется как часть составного ключа, он по-прежнему индексируется и эффективен для выполнения операций, таких как получение всех книг с жанром «X».

BOOK
BookId (PK): number
BookTitle: string
Blurb: string

BOOKGENRE
BookId (CK): number
GenreName (CK): string

Является ли это приемлемой практикой или Требуется ли хранить жанр как отдельную таблицу с ключом?

Answer 1

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

С альтернативным дизайном, о котором вы думаете, что, если вы хотите переименовать жанр, скажем, из Sci-Fi в Science Fiction? Вам нужно будет обновить каждую строку в таблице bookgenre, что излишне сложно.

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