Идентификатор SQL Server GUID (из Active Directory) против Int

Question

Мы перенесли много данных из нашей старой системы заказов.Эта система сохраняла инициалы пользователей в нашей таблице "Заказы" для каждого созданного ими заказа.Теперь, когда у нас есть представление, которое просматривает active directory, я хотел бы обновить эти инициалы с помощью active directory objectguid (или чего-то, что ссылается на guid).Это позволило бы нам изменять инициалы пользователей в active Directory, не беспокоясь об обновлении записей таблицы "Заказы".

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

Answer 1

Я предполагаю , что a ПОЛЬЗОВАТЕЛЬ сущность уже существует в вашем проекте базы данных, однако, если это не так, я полагаю, что ваше решение потребует этого.

Итак, предполагая, что ПОЛЬЗОВАТЕЛЬ сущность существует, как вы описали, вы могли бы поместить идентификатор пользователя (int) в ПРИКАЗЫ таблицу, тем самым связывая все соответствующие ПОЛЬЗОВАТЕЛЬ подробности к ПОРЯДОК, а не просто инициалы (Примечание:Инициалы, возможно, не должны храниться на ПОРЯДОК таблица, а скорее ПОЛЬЗОВАТЕЛЬ или ПОЛЬЗОВАТЕЛЬ_ДЕТАЛИ таблица, хотя и не является предметом данного обсуждения).

Затем вы можете добавить столбец GUID в таблицу USER.Я не думаю, что необходима отдельная таблица подстановки.

Есть смысл?

Answer 2

Производительность индекса в GUID, как правило, ничем не отличается от других индексов в 16-байтовом поле.Где идентификаторы GUID смертельно опасны для производительности, так это когда вы используете их как ключ кластеризации в таблице SQL Server.

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

Для получения дополнительной справочной информации и нескольких отличных комментариев о том, почему GUID создают очень плохие кластеризованные ключи, смотрите блог "Королевы индексации" Кимберли Трипп.:

• Идентификаторы GUID в качестве первичного ключа
• Дебаты по кластеризованному индексу продолжаются....
• Дискуссия о кластеризованном индексе ....снова!

Ее проницательность наиболее ценна - прочтите ее, усвоите ее, следуйте ей!Вы не пожалеете об этом.

Марк