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

14

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

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

Основным преимуществом раскрытия суррогатного ключа является простота использования поля, которое у вас есть.

При каких обстоятельствах лучше напрямую предоставлять суррогатный ключ пользователям?

design database-design relational-database rdbms surrogate-keys PSR
источник
Часть этого вопроса заключается в том, что вам нужно определить «пользователей». Пользователи могут быть потребителями API, которые вы выставляете, или мясистыми людьми. Ответ не будет одинаковым для обоих.
Джеймс Снелл
1
Мясистые люди.
PSR
Каждая ситуация, когда данные могут быть идентифицированы по-разному, должна иметь свой идентификатор. Итак, если новая система соединяется с вашими данными, ожидайте, что у нее будет свой собственный PK и добавьте это к вашим данным. Видимость «уродливых мешков в основном воды» считается «системой» для этого сценария. Мое предпочтительное решение - хранить ключи и временные метки (добавлять, изменять и удалять) для сущностей в специальной таблице. Таким образом, данные могут быть легко распределены.

Ответы:

10

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

Если данные не имеют естественного бизнес-ключа, вы можете добавить дополнительное поле для «бизнес-идентификатора». Это должно быть оптимизировано для процессов, для которых оно используется. Ввод с клавиатуры телефона означает только цифры. По телефону / словесные средства избегайте одинаковых звучащих символов (B / D, M / N и т. Д.). Вы можете даже автоматически сгенерировать некоторую легко запоминающуюся фразу («зеленое желе»).

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

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

Как примечание, когда я говорю «разоблачение» здесь, я имею в виду дать ключ пользователю с ожиданием, что он использует его напрямую (например, позвонив в службу поддержки с номером заказа).

Крис Питман
источник
5
Этот ответ не имеет смысла. Суррогатные ключи никогда не меняются, и вы не доказали, что не открываете их пользователям.
Роберт Харви
1
никогда не говори никогда. Что, если последний дизайн приведет к консолидации записей? Что делать, если вам нужно увеличить и конвертировать от идентичности?
DougM
3
@DougM: Затем запишите записи в новую консолидированную таблицу со своим собственным суррогатным ключом и сохраните исходные ключи в отдельных полях новой таблицы (и поле, которое идентифицирует исходную исходную таблицу) в качестве ссылок, если это необходимо. Такая консолидация должна быть необычайно редкой и только в результате неудачного дизайна. Повторяйте за мной: суррогат. Ключи. Никогда. Изменить. Вот почему они суррогаты.
Роберт Харви
2
@RobertHarvey Я согласен, что суррогатные ключи никогда не должны изменяться, поэтому я думаю, что они создают плохие внешние идентификаторы. В конечном счете, клиент хочет изменить то, как они относятся к записи. На этом этапе вы либо построили всю свою систему на основе неизменяемых суррогатных ключей, либо думали заранее и установили уровень косвенности между бизнес-идентификаторами и суррогатными ключами.
Крис Питман
2
@sqlvogel: Было бы проще, если бы я использовал термин «сгенерированный системой первичный ключ» вместо «суррогат»? Я согласен, что вы можете изменить алгоритм, который генерирует суррогатные ключи, но это не меняет их принципиально неизменного качества.
Роберт Харви
4

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

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

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

Алан Шутко
источник
Если пользователь понимает это и ожидает взаимодействия с ним, то это уже не суррогатный ключ. Суррогатные ключи определены как не имеющие делового значения. То, что это идентификационный номер, не обязательно означает, что это суррогат. Кроме того, «какой-то суррогатный ключ, который идентифицирует меня на основе моего идентификатора участника, даты рождения [...]», не имеет смысла. Вы говорите, что их суррогатный ключ (который не имеет делового значения) идентифицирует вас на основе того, что может составить естественный ключ?
Кайл Маквей
Часто случается так, что вам присваивается идентификационный номер сотрудника, поэтому в системе сотрудников вы отличаетесь от других людей с таким же именем. На вашей страховой карточке может быть указан идентификатор вашей компании и сотрудника. Но компания медицинского страхования часто генерирует свой собственный внутренний идентификатор, который она может использовать во всех своих системах вместо того, чтобы использовать имя, дату рождения и идентификаторы сотрудников, которые она получает от вашего работодателя. Являются ли эти сгенерированные ключи суррогатными или естественными? Зависит от того, кого вы спрашиваете (проверьте 2 альтернативных определения на en.wikipedia.org/wiki/Surrogate_key )
Алан Шутко
1

Вы должны предоставлять суррогатный ключ только в том случае, если это правильно сгенерированный GUID / UUID *. Разоблачение последовательных суррогатных ключей - это номер 4 в топ-10 проблем безопасности OWASP.

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

Питер Тейлор
источник
2
Из вашего ответа неясно, как GUID повышает безопасность.
Роберт Харви
1
@RobertHarvey - я предполагаю, потому что они не последовательны и поэтому не могут быть угаданы.
Бобсон
1
security.stackexchange.com/q/38777
Роберт Харви
@RobertHarvey, уточнил.
Питер Тейлор
1

Если таблица не имеет естественного ключа, суррогатные ключи допускают такие строки.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

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

Теперь, если предположить, что есть важные данные, ссылающиеся на эти суррогатные ключи через внешние ключи, как конечные пользователи узнают, какую строку обновлять, если они не знают значений суррогатных ключей?

Майк Шеррилл 'Cat Recall'
источник
Немного противоречиво маркировать столбец «суррогатный ключ», но затем сказать, что это «искусственные ключи вместо суррогатных ключей». Если вы называете эти искусственные ключи, потому что они не имеют делового значения и служат только уникальными идентификаторами, тогда этот ключ должен быть натурализован (открыт) и должен быть создан новый суррогатный ключ. т. е. переименуйте натурализованный ключ surrogate_key во что-то, имеющее деловое значение, представьте его клиентам и создайте новый аналогичный столбец, который будет истинным заменителем внутренних операций. Меньше, чем идеал, но все же лучше, чем разоблачение настоящего суррогата.
Кайл Маквей
@KyleMcVay: Это не противоречиво. Оно соблюдает значение суррогата , основная идея которого - «заменить». А суррогатный ключ заменяет естественный ключ. (Теория Кодда и реляционная теория в целом используют суррогатный ключ в этом смысле.) Таблица, которая не имеет естественного ключа, не может иметь суррогатный ключ в этом смысле. Но он может иметь произвольное значение, которое используется вместо всего остального. Это то, что я бы назвал искусственным ключом.
Майк Шеррилл "Cat Recall"
Ваши определения не являются неточными, но я думаю, что суррогатный ключ приобрел дополнительное, специфичное для отрасли значение помимо слова суррогат . Если вы собираетесь предоставить ключ клиенту, я бы сказал, что этот ключ теперь имеет деловое значение; оно было натурализовано и теперь должно рассматриваться как логическая часть сущности, которую оно представляет. По этой логике нет такого понятия, как открытый суррогатный ключ. Если вы собираетесь выставить искусственный ключ, это уже не суррогатный ключ, и вам нужен новый.
Кайл МакВей
0

По словам непрофессионала:

  • Суррогаты должны быть скрыты от пользователя.
  • Вы должны предоставить пользователю какой-нибудь другой ключ бизнес-кандидата.
  • Если другой кандидатный ключ не существует, вы должны показать PK. Но в этом случае ПК не считается суррогатом, поскольку он не заменяет другой столбец.
Тулаинс Кордова
источник
Почему ПК должен быть показан? Я думаю, что это мой вопрос - правильно ли автоматически сгенерированный PK называется суррогатным ключом.
PSR
1
@psr В заголовке вашего вопроса написано " суррогатные ключи когда-либо будут выставлены". Я сказал нет. Но вы должны показать какой-то другой ключ. Если другого ключа не существует, вы должны показать единственный ключ, который у вас есть. Тангенциально я поясняю, что в этих случаях ключ на самом деле не является суррогатом, потому что он не заменяет любой другой столбец.
Тулаинс Кордова
Вопрос в том, следует ли добавить столбец или показать ключ, который у вас есть.
PSR
@psr Я перефразировал свой ответ, чтобы сделать его более понятным.
Тулаинс Кордова
1
Я считаю, что это существенно незначительное различие. Если ваше правило состоит в том, что в каждой таблице есть искусственный ключ (который является моим), и что в объединениях участвуют только искусственные ключи (что также является моим принципом), тогда понятие, что ключ является суррогатом, потому что другие ключи могут быть доступно не имеет значения.
Роберт Харви
0

Вы должны ТОЛЬКО выставлять пользователю поле, которое предоставляет полезную информацию пользователю, либо напрямую, либо сообщая вам о дефектах.

и наоборот, вы ВСЕГДА должны раскрывать «суррогатные первичные ключи», когда они являются основным средством идентификации записи (простой или сложной) для взаимодействия, которое выполняет пользователь.

DougM
источник
0

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

предостережение: это предполагает веб-приложение или n-уровневое приложение, где авторизация на стороне сервера возможна / осуществима. Если у вас есть приложение VB, которое непосредственно выполняет sql, это совершенно другая проблема.

GrandmasterB
источник
Как насчет того, чтобы не иметь возможности вставлять, а затем удалять записи, сохраняя связи внешнего ключа, как упоминалось в вопросе?
PSR
Какое это имеет отношение к раскрытию ключа пользователю? Может быть, я не понимаю, как вы используете термин «разоблачение». Я работаю с предположением, что вы имеете в виду «быть увиденным пользователем».
GrandmasterB