Почему aspnet_users использует guid для id, а не увеличивает int? бонусные баллы за помощь в расширении пользовательских полей

Почему aspnet_users использует guid для id, а не увеличивает int?

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

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

Хотя я хотел бы иметь int (удобнее выполнять поиск пользователя и т. д. stackoverflow.com/users/12345/user-name ), поскольку у меня просто будет имя пользователя, я не думаю, что мне нужно нести это элемент вокруг и нести дополнительную сложность поиска, когда мне нужно найти пользователя int.

Спасибо за любую помощь в этом.


authentication asp.net uniqueidentifier guid
person Chris Barry    schedule 04.11.2009    source источник

Ответы (2)


arrow_upward
13
arrow_downward

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

Недостатком использования стандартного уникального идентификатора в SQL (с newid()) в качестве первичного ключа является то, что идентификаторы GUID не являются последовательными, поэтому при создании новых строк они вставляются в произвольную позицию на странице физической базы данных, а не добавляются к конец. Это вызывает серьезную фрагментацию страниц для систем с существенной скоростью вставки. Это можно исправить, используя вместо этого newsequentialid(). Я обсуждал это в более подробно здесь.

Как правило, рекомендуется либо использовать newsequentialid() для первичного ключа GUID, либо просто не использовать GUID для первичного ключа. У вас всегда может быть вторичный индексированный столбец, в котором хранится GUID, который вы можете использовать, чтобы ваши ссылки были уникальными.

person Rex M    schedule 04.11.2009
comment
Спасибо за ответ, поэтому, если я использую встроенную аутентификацию asp.net, использует ли она newsequentialid() в качестве стандарта? Я не понимаю, почему вы никогда не захотите использовать это? - person Chris Barry; 05.11.2009
comment
@optician это не так, но см. эту ссылку, чтобы изменить это: ericswann.org/blog/archive/2008/03/15/ - person Rex M; 05.11.2009

arrow_upward
5
arrow_downward

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

GUID — это круто, потому что они (почти) гарантированно будут уникальными, и вы можете создать их «заранее» в клиентском приложении в коде .NET.

К сожалению, эти люди не знают об ужасных недостатках (ужасная фрагментация индекса и, следовательно, потеря производительности) этих вариантов, когда речь идет о SQL Server. Многим программистам на самом деле все равно, а потом они обвиняют SQL Server в том, что он медленный, как собака.

Если вы хотите использовать GUID для ваших первичных ключей (и у них есть действительно хорошие применения, как указал Рекс М. - в основном в сценариях репликации), то ОК, но обязательно используйте столбец INT IDENTITY в качестве ключа кластеризации в SQL Server, чтобы свести к минимуму фрагментацию индекса и, следовательно, потери производительности.

У Кимберли Трипп, «королевы индексирования SQL Server», есть множество действительно хороших и проницательных статей на эту тему — см. некоторые из моих любимых:

и практически все, что она публикует в своем блоге, заслуживает прочтения.

person marc_s    schedule 04.11.2009