Чи повинен сурогатний ключ коли-небудь піддаватися дії користувача?

14

Часто в таблиці, яка не має природного ключа, користувачам все ж корисно мати унікальний генерований ідентифікатор. Якщо в таблиці є сурогатний первинний ключ (і в такому випадку ви, безумовно, очікуєте, що це буде), чи повинен цей ключ піддаватися користувачеві або для цього потрібно використовувати інше поле?

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

Основна перевага викриття сурогатного ключа - простота використання поля, яке ви все одно маєте.

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

— psr
джерело

Частина цього питання полягає в тому, що вам потрібно визначити "користувачів". Користувачі можуть бути споживачами API, якого ви піддаєте, або м'ясистими людьми. Відповідь не буде однаковою для обох.

— Джеймс Снелл

1

М'ясисті люди.

— пср

Кожна ситуація, коли дані могли бути ідентифіковані по-різному, повинна мати інший ідентифікатор. Отже, якщо нова система з'єднається з вашими даними, очікуйте, що вона має власну ПК та додайте її до своїх даних. Видимість "потворних мішків з переважно водою" вважається "системою" для цього сценарію. Моє переважне рішення - зберігати ключі та часові позначки (додавати, змінювати та видаляти) для сутностей у спеціальній таблиці. Таким чином, дані можуть бути легко розподілені.

10

Потрібно бути готовим до будь-якого ідентифікатора, який піддається користувачам / клієнтам, які потребують змін, а зміна ідентичності рядка в базі даних та розповсюдження цих змін на всі зовнішні ключі - це просто прохання зламати дані.

Якщо в даних немає природного бізнес-ключа, ви можете додати додаткове поле для "ідентифікатора бізнесу". Це слід оптимізувати для процесів, для яких він використовується. Введення телефонної клавіатури означає лише цифрове значення. По телефону / словесні засоби уникайте подібних звукових символів (B / D, M / N тощо). Можна навіть автогенерувати якусь легко запам’ятовувану фразу («зелене желе»).

Ефект цього полягає в тому, що бізнес може згодом змінити те, як вони хочуть звертатися до записів, і єдина зміна схеми даних - або додавання нового стовпця для цього стилю id, або перетворення ідентифікаторів, які вже є. Зміни не поширюються по всій базі даних, і у вас все ще є один ідентифікатор (сурогат), який дійсний з часом.

Коротше кажучи, я б не піддавав сурогатних ключів користувачам. Як зазначають коментарі, сурогатні ключі майже ніколи не повинні змінюватися. І навпаки, підприємства хочуть все змінити. Якщо сурогатний ключ викритий, це лише питання часу, коли бізнес захоче його змінити.

Як зауваження, коли я говорю тут "викрити", я маю на увазі дати ключ користувачеві з очікуванням того, що він буде використовувати його безпосередньо (як, наприклад, зателефонувавши на підтримку зі своїм номером замовлення).

— Кріс Пітман
джерело

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

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

Тепер, припускаючи, що є важливі дані, що посилаються на ці сурогатні ключі через закордонні ключі, як кінцеві користувачі знають, який рядок оновити, якщо вони не знають сурогатних значень ключів?

— Майк Шеррілл "Відкликання котів"
джерело

Позначити стовпчик "суррогат_кілі" трохи суперечливо, але потім сказати, що вони "штучні ключі замість сурогатних ключів". Якщо ви викликаєте ці штучні ключі, оскільки вони не мають ділового значення та слугують лише унікальними ідентифікаторами, тоді цей ключ повинен бути натуралізований (викритий), а також слід створити новий сурогатний ключ. тобто перейменуйте натуралізований сурогатний_кей на щось із діловим значенням, піддайте його клієнтам та створіть новий аналогічний стовпець, який буде справжнім сурогатом для внутрішніх операцій. Менше ідеального, але все ж краще, ніж виставляти справжнього сурогата.

— Кайл Маквей

@KyleMcVay: Це не суперечливо. Він шанує значення сурогату , суттєвою ідеєю якого є "замінити". А сурогатний ключ замінює природний ключ. (Код та теорія реляцій взагалі використовує сурогатний ключ у цьому сенсі.) Таблиця, яка не має природного ключа, не може мати сурогатного ключа в цьому сенсі. Але воно може мати довільне значення, яке використовується замість чого-небудь іншого. Саме так я б назвав штучний ключ.

— Майк Шеррілл 'Відкликання котів'

Ваші визначення не є неточними, але я думаю, що ключ сурогату набув додаткового, галузевого значення, поза словом сурогат . Якщо ви збираєтесь викрити ключ клієнту, я б заперечував, що цей ключ тепер має ділове значення; воно було натуралізовано , і тепер його слід вважати логічно частиною суб'єкта, який він представляє. За цією логікою немає такого поняття, як відкритий сурогатний ключ. Якщо ви збираєтеся виставити штучний ключ, це вже не сурогатний ключ, а вам потрібен новий.

— Кайл Маквей

0

Словами мирянина:

Сурогати повинні бути приховані від користувача.
Ви повинні виставити користувачеві якийсь інший ключ кандидата в бізнес.
Якщо немає іншого ключа-кандидата, ви повинні показати ПК. Але в цьому випадку ПК не вважається сурогатом, оскільки він не замінює іншу колонку.

— Тулан Кордова
джерело

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

— psr

1

@psr У вашому запитанні написано: " Сурогатні ключі колись піддаються" Я сказав ні. Але ви повинні показати якийсь інший ключ. Якщо немає іншого ключа, то ви повинні показати єдиний у вас ключ. Дотично я уточнюю, що в цих випадках ключ насправді не є сурогатом, оскільки він не замінює жоден інший стовпець.

— Тулен Кордова

Питання полягає в тому, чи слід додати стовпець чи показати ключ, який у вас є.

— psr

@psr Я переформулював свою відповідь, щоб зробити її більш зрозумілою.

— Тулен Кордова

1

Я вважаю це суттєво незначним відмінністю. Якщо ваше правило полягає в тому, що в кожній таблиці є штучний ключ (який у мене є), і що в об'єднанні беруть участь лише штучні ключі (що також є моїм принципом), то поняття про те, що ключ є сурогатом, оскільки, можливо, інші ключі доступний не має наслідків.

— Роберт Харві

0

ви повинні ТИЛЬКО розкривати поле для користувача, яке надає корисну інформацію користувачеві, безпосередньо чи повідомляючи про вади.

навпаки, вам слід ВИНАГИ викривати "сурогатні первинні ключі", коли вони є основним засобом ідентифікації запису (простого або складного) для взаємодії, яку здійснює користувач.

— ДугМ
джерело

0

Не має значення, відкриваєте ви ключі чи ні кінцевому користувачеві. Ваша програма повинна виконати необхідну авторизацію, щоб, наприклад, просто знаючи ідентифікатор замовлення, не дозволяв їм отримати доступ до того, до чого вони зазвичай не мали б доступу.

Застереження: це передбачає веб-або n-ярусне додаток, де авторизація на стороні сервера можлива / можлива. Якщо у вас є додаток VB, яке безпосередньо виконує sql, це ціла проблема.

— ГрандмайстерB
джерело

А як бути не в змозі вставити, а потім видалити записи, зберігши зовнішні ключові зв’язки, про що йдеться у запитанні?

— пн

Що це стосується викриття ключа для користувача? Можливо, я не розумію вашого використання терміна "викриття". Я працюю з припущення, що ви маєте на увазі "вміє бачитись користувачем".

— GrandmasterB