Поставщик членства ASP.NET, GUID идентификатора пользователя и дисковое пространство

Question

В настоящее время я использую поставщик членства SQL для ASP.NET, который использует идентификаторы GUID для идентификатора пользователя. Мое приложение имеет несколько пользовательских таблиц, которые имеют отношения внешних ключей обратно к таблице User, и меня беспокоит дисковое пространство и последствия использования стандартного поставщика GUID для идентификатора пользователя.

Кто-нибудь сталкивается с проблемами, связанными с пространством/производительностью, связанными с этим, и если есть ли там индивидуальные подходы, которые люди внедрили для решения этой проблемы?

Любое понимание или предложения были бы наиболее ценными.

Благодаря

Answer 1

Я сомневаюсь, что у вас возникнут проблемы с пространством в результате использования GUID, а не типов INT. Одна вещь, о которой я вам предупреждаю, заключается в том, что у вас может возникнуть соблазн создать кластерные индексы в столбцах GUID в базе данных. НЕ ДЕЛАЙ ЭТО. По умолчанию GUID являются случайными и вставка случайных данных в столбец с кластеризованным индексом вызывает несколько проблем. Кластерное, как вы знаете, означает «ФИЗИЧЕСКАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ПО ХРАНЕНИЮ». Поэтому, когда вы вставляете новое случайное значение (GUID), эта строка обычно должна быть вставлена ​​в середину таблицы. Это может привести к массово фрагментированным индексам.

Моим советом было бы создать таблицу, связывающую идентификаторы GUID с INT (BIGINT, если вы ожидаете, что многие пользователи), а затем использовать INT везде. Как сказал Фермин.

Answer 2

Могли бы вы не иметь пользовательские таблицы, отображающие GUID в целое значение, которое затем можно использовать целое число в пользовательских таблицах?

UserId guid 
FriendlyUserId int //use this as FK in other tables? 

Answer 3

Если вы используете SQL Server 2005, вы можете посмотреть на метод NewSequentialId(). Eric Swann предоставляет good overview его использование с поставщиком членства. Существует также nice article о преимуществах использования последовательных GUID по случайным случайным значениям по умолчанию. Вот выдержка из сравнения производительности из статьи ...

    [Reads] [Writes] [Leaf Pages] [Avg Page Used] [Avg Fragmentation] [Record Count] 
    IDENTITY(,)  0  1,683  1,667  98.9%   0.7%    50,000 
    NEWID()   0  5,386  2,486  69.3%   99.2%    50,000 
    NEWSEQUENTIALID() 0  1,746  1,725  99.9%   1.0%    50,000