Разоблачение суррогатного ключа для пользователей

Question

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

Идея состоит в том, чтобы избежать потенциальных проблем в будущем.Если ключ является полем идентификации, автоматически сгенерированным dbms, тогда вы не можете контролировать ключ.Я использую NHibernate в своем приложении, поэтому я могу контролировать ключ с помощью HiLo, как описано здесь , который я намерен использовать.В случае, если это имеет значение, СУБД - это Oracle.

С какими потенциальными проблемами я мог бы столкнуться в будущем, выставив ключ?

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

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

Спасибо!

Answer 1

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

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

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

Answer 2

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

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

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

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

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

(Существуют исключения, но их не много.)

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

id    title
--
1     An Introduction to Database Systems
2     An Introduction to Database Systems
3     An Introduction to Database Systems
4     An Introduction to Database Systems
8     An Introduction to Database Systems
15    An Introduction to Database Systems
37    An Introduction to Database Systems

Но, скрывая суррогат, пользователь видит это.

title
--
An Introduction to Database Systems
An Introduction to Database Systems
An Introduction to Database Systems
An Introduction to Database Systems
An Introduction to Database Systems
An Introduction to Database Systems
An Introduction to Database Systems

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

Answer 3

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

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

если это действительно бизнес-требование, чтобы пользователь увидел идентификатор:

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

2. да, в любом случае - тождество или хило - вы можете изменить начальное значение тождества или обновить таблицу hibernate_unique_key, чтобы обновить диапазон для новых идентификаторов. Я бы порекомендовал, чтобы при использовании nhibernate вы никогда не использовали идентичность и всегда отдавали предпочтение hilo (или guid). генератор идентификаторов требует перехода в базу данных для получения идентификатора и отличается от того, как nhibernate любит работать с пакетированием операций в сеансе и переходом в базу данных при сбросе. некоторые вещи не работают так же хорошо с nhibernate, и вы увидите тонкие и неожиданные ошибки, если будете использовать идентичность, потому что nhibernate делает некоторые вещи не так, как вы ожидаете в этом случае (а некоторые вещи просто не работают).

3. да, это, безусловно, варианты.

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

Answer 4

Ну, первые три вопроса легко

1. Нет, не легко. Это главное преимущество суррогатных ключей. Ключи-кандидаты, которые могут измениться, могут вызвать проблемы, если они являются Первичным ключом.
2. Да, но не стоит из-за # 1
3. Да, и вы должны.

Этот жестче.

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

Но есть две общие проблемы.

1. Пользователи привыкли видеть приращение числа без дырок. Но рано или поздно они получат один или много, и они попросят заполнить эти отверстия. У них не так много веских причин для этого, и вам нужно от этого отказаться.

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

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