Хеши по сравнению с Числовым идентификатором
str() создает строку, подобную "['first', 'second', 'third', 'fourth']".
И s.join() обрабатывают строку как массив символов. Затем он помещает '/' между каждым элементом в массиве.
7 ответов
Если вы не пытаетесь скрыть состояние своего внутреннего счетчика идентификаторов объектов, хэши будут излишне медленными (для генерации и сравнения), излишне длинными, излишне уродливыми и излишне способными к конфликтам. GUID также длинные и уродливые, что делает их столь же непригодными для человеческого употребления, как и хэши.
Для вещей, подобных инвентарю, просто используйте вместо этого последовательный (или сегментированный) счетчик. Если вы переходите к другой базе данных, вам просто нужно будет инициализировать новый счетчик значением, по крайней мере, таким же большим, как ваш самый большой существующий идентификатор записи. Практически каждый сервер базы данных дает вам возможность сделать это.
Если вы пытаетесь скрыть состояние своего счетчика, возможно, потому, что вы подсчитываете пользователей и не хотите, чтобы конкуренты знали, сколько у вас их количество, я предлагаю избегать отображения ваших внутренних идентификаторов. . Если вы настаиваете на их отображении и не хотите недостатков хэша, вы можете рассмотреть возможность использования сдвигового регистра с линейной обратной связью с максимальным периодом для генерации идентификаторов.
Хеши, как гарантируют, не будут уникальны, ни, я верю, последовательный.
Используя хеши предпочтительно в случае, если необходимо восстановить базу данных по некоторым причинам, например, и изменения упорядочивания. Порядковые числа переместятся - но хеши останутся такими же.
Не полагаясь на порядок Вы помещаете вещи в поле, но на свойствах вещей, просто кажется.. более безопасный.
Но не упустите коллизии, очевидно.
Я обычно использую хеши, если я не хочу, чтобы пользователь смог предположить следующий идентификатор в ряду. Но для Ваших книжных разделов, я придерживался бы числового идентификатора.
Ваши пользователи должны будут помнить/использовать значение? или Вы смотрите на него от безопасности POV?
С точки зрения безопасности это не должно иметь значения - так как Вы не должны только полагаться на людей, не предполагающих другой, но действительный идентификатор чего-то, что они не должны видеть для не допускания их.
Да, я не думаю, что Вы ищете хеш - Вы более вероятно ищете Гуид. Если Вы находитесь на платформе .NET, попробуйте Систему. Гуид.
Однако самая важная причина не использовать Гуид для производительности. Выполнение соединений базы данных и поисков на (длинных) строках является очень субоптимальным. Числа быстры. Так, если Вам действительно не нужен он, не делайте этого.
С хешами вы
- Вольны объединить базу данных с аналогичной (или создать резервную копию), если необходимо
- . Не делаете ничего, что могло бы хоть немного помочь некоторым атакам на угадывание.
- Не раскрывают больше личной информации о пользователе, чем необходимо, например, если кто-то видит пользователя номер 2 в вашем текущем входе в базу данных, он получает информацию о том, что он старый.
- (При условии, что вы используете длинный хэш или GUID), очень помогая себе, если вы куплены YouTube, и они решают интегрировать ваши базы данных.
- Помогая себе, если появляется поисковая система, которая индексирует по GUID.
Пожалуйста, дайте нам знать если последние 6 месяцев внесли ясность в этот вопрос ...