Должен ли я использовать столбцы естественной идентичности без GUID?

Question

Можно ли определить первичный ключ таблицы с двумя столбцами внешнего ключа, которые в комбинации должны быть уникальными? И, таким образом, не добавить новый столбец идентификатора (Guid или int)?

Есть ли минус к этому?

Answer 1

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

Answer 2

Естественные и искусственные первичные ключи - это одна из тех проблем, которая широко обсуждается, и ИМХО, похоже, обсуждение только укрепляет позиции.

По моему мнению, оба работают, пока разработчик знает, как избежать недостатков обоих. Естественный первичный ключ (будь то составной или одиночный столбец) почти гарантирует, что повторяющиеся строки не будут добавлены в БД. В то время как с искусственными первичными ключами необходимо сначала проверить, что запись уникальна (в отличие от первичного ключа, который, будучи искусственным, всегда будет уникальным). Одним из эффективных способов достижения этого является наличие уникального индекса или индекса кандидата в полях, которые делают запись уникальной (например, в полях, которые делают кандидата в первичный ключ)

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

Answer 3

Да, я согласен, с «некоторым определением ОК» все в порядке. Но в тот момент, когда вы решаете сослаться на этот составной первичный ключ откуда-то (то есть переместить его во внешний ключ), он быстро превращается в NG (Not Good).

Answer 4

Если вы заглянете в любой учебник по базе данных, вы найдете такие таблицы в большом количестве. Это стандартный способ определения отношений n-to-m. Например:

article = (id, title, text)
author = (id, name)
article_author = (article_id, author_id)

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

Answer 5

Для некоторых определений «ок» да. Пока вы не собираетесь добавлять дополнительные поля в эту таблицу пересечений, это будет хорошо. Однако, если вы хотите иметь больше полей, рекомендуется иметь поле идентификатора. Это все еще хорошо, если подумать, но может быть более неловко.

Если, конечно, дисковое пространство стоит серьезной премии!