Замена последовательности со случайным числом
Кодирование должно только только только быть сделано в дисплее. Без исключения.
5 ответов
Для генерации уникальных и случайных идентификаторов из серийного номера хорошей идеей может быть использование шифров. Так как их выходные данные биективны (между входными и выходными значениями существует взаимно однозначное соответствие), у вас не будет никаких конфликтов , в отличие от хэшей. Это означает, что ваши идентификаторы не обязательно должны быть такими же длинными, как хэши.
Большинство криптографических шифров работают с 64-битными или более крупными блоками, но в вики PostgreSQL есть пример процедуры PL / pgSQL для «некриптографических» "cipher функция, работающая с (32-битным) int типом. Заявление об ограничении ответственности: я сам не пробовал использовать эту функцию.
Чтобы использовать ее для ваших первичных ключей, запустите вызов CREATE FUNCTION со страницы вики, а затем в ваших пустых таблицах выполните:
ALTER TABLE foo ALTER COLUMN foo_id SET DEFAULT pseudo_encrypt(nextval('foo_foo_id_seq')::int);
И вуаля!
pg=> insert into foo (foo_id) values(default);
pg=> insert into foo (foo_id) values(default);
pg=> insert into foo (foo_id) values(default);
pg=> select * from foo;
foo_id
------------
1241588087
1500453386
1755259484
(4 rows)
Я думаю, вы слишком усложняете это. Почему бы не позволить базе данных делать то, что у нее получается лучше всего, и позволить ей позаботиться об атомарности и гарантировать, что один и тот же идентификатор не используется дважды? Почему бы не использовать тип postgresql SERIAL и не получить автоматически сгенерированный суррогатный первичный ключ, как целочисленный столбец IDENTITY в SQL Server или DB2? Вместо этого используйте это в столбце. Кроме того, это будет быстрее, чем ваша пользовательская функция.
Я согласен относительно сокрытия этого суррогатного первичного ключа и использования открытого вторичного ключа (с уникальным ограничением на него) для поиска клиентов в вашем интерфейсе.
Вы используете последовательность, потому что вам нужен уникальный идентификатор в нескольких таблицах? Обычно это признак того, что вам нужно переосмыслить дизайн своей таблицы, и эти несколько таблиц, возможно, следует объединить в одну, с автоматически сгенерированным суррогатным первичным ключом.
Также см. здесь
Лучше всего, вероятно, будет какая-нибудь хеш-функция, а затем в конец будет добавлена контрольная сумма.
Я добавил свой комментарий к вашему вопросу, а затем понял, что мне следовало объяснить себя лучше ... Мои извинения.
Вы могли бы иметь второй ключ, а не первичный, который виден пользователю. Этот ключ может использовать первичный элемент в качестве начального числа для описываемой хеш-функции и быть тем, который вы используете для поиска. Этот ключ будет сгенерирован триггером после вставки (что намного проще, чем пытаться обеспечить атомарность операции) и
Это ключ, которым вы делитесь со своими клиентами, никогда ПК. Я знаю, что ведутся споры (хотя я не могу понять почему), должны ли PK быть невидимыми для пользовательских приложений или нет. Современные методы проектирования баз данных и мой личный опыт, похоже, говорят о том, что PK НЕ должны быть видимы для пользователей. Они, как правило, придают им значение, и со временем это очень плохо - независимо от того, есть ли у них контрольная цифра в ключе или нет.
Ваши соединения по-прежнему будут выполняться с использованием PK. Этот другой сгенерированный ключ просто должен использоваться для поиска клиентов. Они - лицо, ПК - это кишки.
Надеюсь, что это поможет.
Edit: FWIW, мало что можно сказать о "правильном" или "неправильном" в дизайне базы данных. Иногда все сводится к выбору. Я думаю, что выбор, с которым вы столкнетесь, будет лучше, если оставить PK в покое и создать вторичный ключ - вот и все.
Если вы не используете это слишком часто (у вас нет нового клиента каждую секунду, не так ли?), То можно просто получить случайное число, а затем попытаться вставить запись. Просто будьте готовы повторить попытку вставки с другим номером, если это не удается из-за нарушения уникального ограничения.
Я бы использовал числа от 1000000 до 999999 (900000 возможных чисел одинаковой длины) и проверял цифру, используя алгоритм UPC или ISBN 10 . Тем не менее, было бы лучше использовать 2 контрольных цифры, так как они устранят 99% человеческих ошибок вместо 9%.