Уникальные идентификаторы для пользователей

Если вы используете MSSQL, вы можете создать PK своей таблицы как UNIQUEIDENTIFIER и установить значение по умолчанию или привязку на NEWID ().

Стандартным решением здесь является использование GUID. Однако они не будут работать так же хорошо с точки зрения индексации.

GUID хороши, но могут конфликтовать (хотя и редко).

Это может быть нестандартное решение, но я собираюсь его выбросить:

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

Допустим, у вас 3 сервера. Запишите идентификаторы следующим образом:

Сервер 1: 0 - 9 999 999
Сервер 2: 10 000 000 - 19 999 999
Сервер 3: 20 000 000 - 29 999 999

Даже в пределах ограничений 32-битного int, который должен оставить много места для расширения (можно даже использовать пробелы в 100000000, если вы беспокоитесь), и по сути гарантирует уникальность во всей системе.

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

Используйте целочисленный ключ и для каждого нового узла / сайта

• увеличивайте с шагом 10. При добавлении узлов просто начинайте с 2, 3 и т. Д.
• Используйте диапазоны, например, 1- > 1000000, 1000000 -> 1999999 и т. Д.
• И не забывайте -ve тоже. Например, вы можете иметь IDENTITY (-1, -1) для 2-го узла

. Если у вас есть узлы / сайты, то второй столбец с SiteID также будет работать.

GUID - простой выход, но ...

Насколько распределенным он должен быть? Если количество баз данных ограничено, вы можете дать каждой базе данных диапазон используемых номеров. Так, например, первая база данных автоматически генерирует числа в диапазоне от 0 до 999 999, а следующая использует от 1 000 000 до 1 999 999. Таким образом, каждый из них может генерировать идентификатор пользователя, не сталкиваясь друг с другом. Если база данных включает уникальный номер, идентифицирующий его, тогда диапазоны могут быть автоматически сгенерированы из этого номера.

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

если вам нужны миллионы идентификаторов и у вас много узлов, сделайте первичный ключ составным:

NodeID  int   --unique for each node 2 or 4 byte  
UserID  int   --auto increment 8 byte, repeats for each node

что намного лучше, чем GUID (меньше, использует меньше памяти и будет быстрее)

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

Вы можете использовать GUIDS. Но 5 миллионов - это ничто с точки зрения данных и, вероятно, не потребуют изменений. В нашей системе работает более 10 000 000 различных людей, и у нас есть только база данных среднего размера без разделения на разделы или необходимости в GUID.

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

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

Я бы порекомендовал следующие два решения.

1. если вы можете создать составные ключи, которые будут идеальными, например, если это программное обеспечение банка, тогда может быть BranchId, transactionId станет первичным ключом, где branchId - это идентификатор узла, вставляющего запись, а transactionId - это автоматическое число в филиале, поэтому вы полностью обретет уникальность.

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

, я понимаю, что второй решение немного запутанное и сложное, но все же лучше, чем использование Guids в качестве ПК. но если решение 1 применимо, сделайте это.

Когда я говорю «Стоимость» - это не только время обработки, но и время блокировки (ожидания), что является пустой тратой денег, и ваш четырехъядерный сервер может выполнять половину его работы, а большее количество блокировок означает большую вероятность возникновения взаимоблокировок, поэтому мой друг никогда не пользуется гидами.

С уважением, Мубашар