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

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

1 голос
/ 14 мая 2009

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

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

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

Спасибо

Ответы [ 3 ]

5 голосов
/ 14 мая 2009

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

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

1 голос
/ 14 мая 2009

Если вы используете SQL Server 2005, возможно, вы захотите взглянуть на метод NewSequentialId(). Eric Swann предоставляет хороший обзор его использования с поставщиком членства. Есть также хорошая статья о преимуществах использования последовательных идентификаторов 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
1 голос
/ 14 мая 2009

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

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