Каков предпочтительный метод генерации локально уникальных идентификаторов в VB.NET?

Question

Я ищу способ генерации уникальных идентификаторов для класса записи, создаваемого локально, а затем сохраняющегося в различных форматах (XML, SQL и т. Д.)

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

GUID немного переборщил, так как мне не нужно ничего уникального (большого) на глобальном уровне. Я также знаю об использовании GUID и GetHashCode, чтобы немного уменьшить размер, но дубликаты также появляются здесь.

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

Answer 1

Руководящий или увеличивающий счетчик.

Guid может быть сгенерирован «из воздуха», но занимает больше места

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

Answer 2

GetHashCode определенно не очень хороший выбор.

Насколько велик идентификатор?

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

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

Answer 3

Это почти всегда ошибка, чтобы реализовать свои собственные. Маленькие уникальные номера требуют действительно надежную запись последнего использованного номера. Это трудно понять, на жестких дисках есть сбои в работе, реестры иногда повреждаются. Вам нужно будет организовать его, чтобы была одна точка отказа. Подобно столбцу с автоматическим добавлением dbase. Убедитесь, что есть потеря последнего номера, есть также полная потеря данных. Это означает, что для одного не должно быть способа для пользователя копировать данные, не копируя также запись последнего номера. Или у вас всегда есть надежная копия всего данных и вы можете восстановить последний номер из него. Быстро.

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

Тогда есть нагрузка угадать, что произойдет через 10 или 20 лет. Будет ли ваше приложение масштабироваться для удовлетворения требований к тому времени? Это очень редкий, считая, что машины быстрее развиваются. Теперь местный уникальный номер должен стать глобально уникальным номером. Очень Различные требования на этом.

Не шуните с этим, 16 байт - ничто. Используйте руководство.