Когда вам когда-нибудь понадобится изменить значение первичного ключа?

Я читал о внешних ключах и т. д. для postgres и заметил, что он допускает каскадное обновление для внешних ключей.

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

Очевидно, этому парню нужно http://www.oreillynet.com/onlamp/blog/2004/10/hey_sql_fans_check_out_foreign.html, но я не совсем понимаю, как это может быть полезно.

Изменить: я вижу естественные первичные ключи, как это можно использовать. Но как насчет технических первичных ключей? Те, которые не имеют смысла и почти всегда автоматически генерируются при вставке?


sql primary-key foreign-keys
person Earlz    schedule 17.02.2010    source источник

Ответы (7)


arrow_upward
2
arrow_downward

Ну... у нас есть много первичных ключей, которые определены как удобочитаемый код. Ужасная идея, но выбор невелик.

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

person Andrew Backer    schedule 17.02.2010

arrow_upward
1
arrow_downward

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

Мораль истории: не используйте естественные ключи в качестве первичных.

person Mark Byers    schedule 17.02.2010
comment
Я не использую ничего, кроме serial (автоматически увеличивающийся уникальный номер) для первичных ключей, потому что использование чего-либо еще в основном запрещено там, где я работаю (и на то есть веские причины) - person Earlz; 18.02.2010
comment
Как насчет таблицы, описывающей отношение многие ко многим, где первичный ключ представляет собой комбинацию двух связанных внешних ключей? Вам ведь не нужен лишний серийный первичный ключ? - person Mike Sherov; 18.02.2010
comment
@Mike Sherov: +1 Вы правы: вам не нужно иметь лишний столбец только для создания первичного ключа без уважительной причины. Если у вас уже есть подходящий ключ-кандидат (т. е. не естественный ключ), вы можете и должны использовать его в качестве первичного ключа. Обратите внимание, что если вы ссылаетесь на таблицу с внешним ключом из двух столбцов, создание избыточного столбца может повысить производительность. В другом случае лишний столбец не нужен, если вы моделируете набор (т.е. таблицу, состоящую только из одного столбца, где важной деталью является наличие или отсутствие элемента в наборе). - person Mark Byers; 18.02.2010
comment
Привет, Марк, всегда рад видеть твои ответы. Важной вещью, которую я пытался сообщить @Earlz (полагаю, мой риторический вопрос должен был быть ответом), было то, что вы только что сказали. Не используйте естественные ключи в качестве первичных ключей, но серийные ключи также не всегда являются правильным ответом... Я бы сказал, всегда сначала ищите подходящий ключ-кандидат (и обычно вы можете найти хороший, когда ваша таблица описывает отношения между более чем одной из других таблиц в БД). - person Mike Sherov; 18.02.2010
comment
Я не вижу проблемы с естественными ключами, если они не будут меняться в домене вашего приложения. Фамилии - плохой выбор. Номера социального страхования могут меняться и, вероятно, не должны использоваться в любом случае из соображений конфиденциальности. Коды ISBN и UPC/EAN должны подойти (независимо от производителей, которые повторно используют их в аналогичных продуктах), поскольку их единственная причина для изменения — добавить больше цифр. Я могу ошибаться, но я сомневаюсь, что Amazon будет иметь синтетический ключ в дополнение к (видимому пользователю) ASIN для каждого продукта. - person Duncan; 18.02.2010

arrow_upward
1
arrow_downward

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

Через несколько раз мы просто перестали выставлять ПК и добавили новую колонку.

person anthares    schedule 17.02.2010

arrow_upward
1
arrow_downward

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

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

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

person ConcernedOfTunbridgeWells    schedule 17.02.2010

arrow_upward
1
arrow_downward

Вы можете попасть в эту ситуацию, если используете естественный первичный ключ.

Вот один очень свежий пример: в Хорватии правительство изменило налоговые номера как для компаний, так и для физических лиц. Новый закон был введен с 1 января 2010 года.

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

person zendar    schedule 17.02.2010

arrow_upward
1
arrow_downward

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

person Dana the Sane    schedule 18.02.2010

arrow_upward
0
arrow_downward

Вам может понадобиться сделать это, если вы используете естественный первичный ключ (тот, который имеет реальное значение в проблемной области). Если значение изменилось, вам нужно каскадировать изменение.

Я предположил, что плохим примером этого может быть база данных зданий в школьном городке с названием здания в качестве первичного ключа (не делайте этого дома). Если здание будет переименовано в взятку в честь нового жертвователя, то ключ нужно будет изменить.

person John Saunders    schedule 17.02.2010