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

87
10

Привлекательность первичного ключа


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


Я просто добавил первичный ключ (в Views) с нулями, чтобы успокоить их желание сделать контрольный номер сложным, умным и привлекательным. Но они хотели, чтобы это было: первые 2 цифры в качестве кода клиента, затем 4 цифры в год, а затем последние 4 цифры в качестве номера транзакции на этом клиенте в течение данного года, а затем reset номер транзакции клиента до 1, когда в следующем году, Каждая транзакция клиента начинается с 1. например. WM20090001, WM20090002, BB2009001, WM20100001, BB20100001


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


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


    Как вы справляетесь с этими пользовательскими запросами (разумными или другими)?
    Вы уступаете их просьбе?
    Или просто продолжайте использовать немой первичный ключ и объясните им последствия наличия очень умного/сложного первичного ключа и ознакомьте их с важными преимуществами наличия немого первичного ключа?

P.S.


quotable quote (https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1044961.html):


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


спросил(а) 2010-04-23T06:36:00+04:00 10 лет, 2 месяца назад
1
Решение
109

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


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

Объясняя, что они bikeshedding, вероятно, не сработают в ваших интересах. Обратите внимание на выраженную потребность клиента, что ваша работа.

ответил(а) 2010-04-23T06:44:00+04:00 10 лет, 2 месяца назад
78

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

На самом деле, моя лучшая работа с базами данных - моя текущая работа - приходила ко мне в основном потому, что парень до меня не понял этого. Он бесконечно спорил с менеджерами о немых номерах и непреклонно отказывался предоставить что-либо еще. Все, что я должен был сделать, это обещание "не быть таким".

ответил(а) 2010-04-23T06:43:00+04:00 10 лет, 2 месяца назад
38

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


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


Знание - это сила. То есть данные. Когда данные становятся доступными, питание становится общим. Когда власть делится, происходит политика. Дипломатия - часть работы.

ответил(а) 2010-04-23T09:09:00+04:00 10 лет, 2 месяца назад
39

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


Точный дизайн и реализация их данных в базе данных должны рассматриваться как черный ящик для конечных пользователей. Суть в том, что вывод этого черного ящика - это данные в правильном формате, который им нужен: пользователям не нужно или нужно знать, действительно ли данное поле является PK или сгенерировано из него.

ответил(а) 2010-04-23T07:01:00+04:00 10 лет, 2 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема