Когда наличие столбца идентификаторов не является хорошей идеей?

Question

В таблицах, где вам нужен только 1 столбец в качестве ключа, а значения в этом столбце могут быть целыми числами, если не следует использовать поле идентификатора?

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

Полагаю, это будет тот случай, когда в таблицу будет много вставок и удалений. Я прав? Какие еще могут быть ситуации?

Answer 1

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

Answer 2

Полагаю, если вы создаете таблицу связывания «многие ко многим», где оба поля имеют значение внешние ключи , вам не нужно поле идентификации.

В настоящее время я представляю, что большинство ORM ожидают, что в каждой таблице будет поле идентичности. В общем, это хорошая практика.

Answer 3

Я не уверен, что достаточно хорошо понимаю ваш контекст, но я интерпретирую ваш вопрос следующим образом:

«Если мне нужна база данных для создания уникального столбца (по какой-либо причине), когда это не должен быть монотонно увеличивающийся столбец целых чисел (идентификаторов)?»

В этих случаях нет причин использовать что-либо, кроме средства, предоставляемого СУБД для этой цели; в вашем случае (SQL Server?) это личность.

За исключением:

Если вам когда-нибудь понадобится объединить таблицу с данными из другого источника, используйте GUID, который предотвратит столкновение повторяющихся ключей.

Answer 4

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

Answer 5

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

Answer 6

Недавно я реализовал Suffix Trie в C #, который может индексировать романы, а затем позволять выполнять поиск очень быстро, линейно по размеру строки поиска. Часть требований (это было домашнее задание) состояла в том, чтобы использовать автономное хранилище, поэтому я использовал MS SQL, и мне была нужна структура для представления узла в таблице.

Я получил следующую структуру: NodeID Character ParentID и т. Д., Где NodeID был первичным ключом.

Я не хотел, чтобы это делалось как автоинкрементная идентичность по двум основным причинам.

1. Как получить значение NodeID после добавления его в базу данных / таблицу данных?
2. Я хотел больше контроля, когда речь шла о генерации моих собственных идентификаторов.

Answer 7

Если мне нужен суррогат, я бы использовал либо столбец IDENTITY, либо столбец GUID в зависимости от необходимости глобальной уникальности.

Если существует естественный первичный ключ или первичный ключ определен как уникальная комбинация других внешних ключей, то у меня обычно нет ИДЕНТИЧНОСТИ, и при этом я не использую его в качестве первичного ключа.

Исключение составляют таблицы конфигурации моментальных снимков, которые я отслеживаю с помощью триггера аудита. В этом случае обычно существует логический «первичный ключ» (обычно дата снимка и естественный ключ строки - например, учетный центр или номер счета gl, для которого строка является записью конфигурации), но вместо использования естественного «первичный ключ» в качестве первичного ключа, я добавляю IDENTITY и делаю его первичным ключом, а также создаю уникальный индекс или ограничение по дате и естественному ключу. Хотя теоретически дата и естественный ключ не должны изменяться, в этих таблицах, если пользователь делает это вместо добавления новой строки и удаления старой строки, я хочу провести аудит (который отражает изменение строки, идентифицируемой его первичным ключом). ) чтобы действительно отразить изменение в строке - не исчезновение ключа, а появление нового.

Answer 8

Нельзя (обычно) указывать значения при вставке в столбцы идентификаторов, например, если в качестве идентификатора был указан столбец "id", следующий SQL-запрос завершится ошибкой:

INSERT INTO MyTable (id, name) VALUES (1, 'Smith')

Чтобы выполнить вставку такого типа, необходимо включить IDENTITY_INSERT для этой таблицы - она ​​не предназначена для нормальной работы и может быть включена только для максимум 1 таблицы в базе данных в любой момент времени. 1004 *