GUID как FK-некластеризованный индекс SQL Server 2017 - PullRequest
Новая
       38

GUID как FK-некластеризованный индекс SQL Server 2017

0 голосов
/ 28 января 2019

Я проектирую полностью систему, которая будет работать как в подключенном, так и в неподключенном режимах, и в настоящее время я моделирую БД.Кстати, я использую ASP NET Core, EF Core 2.2 и SQL Server 2017. После прочтения соответствующей документации и консультаций по другим вопросам на подобных форумах я решил использовать следующий подход:

PK:Guid, некластеризованный индекс 

builder.HasKey(e => e.Id)
       .ForSqlServerIsClustered(false); //Reduce fragmentation.

Теперь, когда я понимаю, что EF Core будет пытаться добавить Guid как последовательный, я установил значение по умолчанию NEWID () по соображениям безопасности: 

builder.Property(e => e.Id)
       .HasColumnName($"{typeof(TEntity).Name}Id")
       .ValueGeneratedOnAdd()
       .HasDefaultValueSql("NEWID()");

Чтобы таблица не была кучей, я использовал второй столбец типа Int в качестве кластерного индекса.Это также Identity and Unique: 

builder.HasIndex(e => e.ClusteredIndex)
       .ForSqlServerIsClustered(true)
       .IsUnique();

builder.Property(e => e.ClusteredIndex)
       .UseSqlServerIdentityColumn()
       .ValueGeneratedOnAdd();

Мой вопрос: как влияет на производительность использование GUID в качестве FK?У меня есть некоторые мысли по этому поводу, но я предпочитаю спросить.Я думал об использовании Int (Clustered Index) в качестве FK, но значение этого поля можно повторить, когда клиент работает в автономном режиме.Поэтому я решил не синхронизировать его и настроить как уникальный, поэтому я могу использовать только GUID в качестве FK в отношениях.Я понимаю, что некластеризованный индекс будет указывать на кластеризованный индекс таблицы.

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

Что не так с этим подходом?Как это можно улучшить?

Заранее спасибо.

...