Хеши против числовых идентификаторов

Question

При создании веб-приложения, которое каким-то образом отображает отображение уникального идентификатора для повторяющегося объекта (видео на YouTube или раздел книги на сайте, подобном моему), было бы лучше использовать идентификатор одинаковой длины, такой как хеш или уникальный ключ элемента в базе данных (1, 2, 3 и т. д.).

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

Вкратце: Что лучше использовать в качестве публично отображаемого уникального идентификатора - хеш-значение или уникальный ключ из базы данных?

Редактировать : Я снова открываю этот вопрос, потому что Дмитрий поднял хорошую мысль о том, что не нужно связывать именование с конкретной собственностью БД. Не помешает ли мне такая оптимизация / нормализация базы данных в будущем?

Платформа использует php / python с ISAM / w MySQL.

Answer 1

Если вы не пытаетесь скрыть состояние своего внутреннего счетчика идентификаторов объектов, хэши будут излишне медленными (генерировать и сравнивать), излишне длинными, излишне уродливыми и излишне способными к столкновению. GUID также длинные и некрасивые, что делает их такими же непригодными для потребления человеком, как и хэши.

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

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

Answer 2

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

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

Но следите за столкновениями, очевидно.

Answer 3

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

Answer 4

С хэшами вы

1. При необходимости можно объединить базу данных с аналогичной (или резервной)
2. Не делают чего-то, что могло бы помочь некоторым угадываниям атак даже немного
3. Не разглашает больше личной информации о пользователе, чем необходимо, например, если кто-то увидит пользователя с номером 2 в вашей текущей базе данных, он получит информацию, что он старенький.
4. (при условии, что вы используете длинный хеш или GUID), очень помогающий вам в случае, если вы купили YouTube, и они решили интегрировать ваши базы данных.
5. Помогите себе, если появится поисковая система, которая индексирует по GUID.

Пожалуйста, дайте нам знать, если последние 6 месяцев принесли вам ясность в этом вопросе ...

Answer 5

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

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

Answer 6

Да, я не думаю, что вы ищете хеш - вы, скорее всего, ищете Guid. Если вы на платформе .Net, попробуйте System.Guid.

Однако, самая важная причина не использовать Guid - это производительность. Выполнение соединений с базами данных и поиск (длинных) строк очень неоптимален. Номера быстрые. Так что, если вам это действительно не нужно, не делайте этого.

Answer 7

ваши пользователи должны будут помнить / использовать значение? или ты смотришь на это с точки зрения безопасности?

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

Answer 8

Хэши не гарантированно ни уникальны, ни, я считаю, непротиворечивы.