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

Question

первичный ключ привлекательности

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

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

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

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

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

приписка

цитата (https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1044961.html):

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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