Почему в EF Core 2.2 для первичного ключа по умолчанию задано значение nvarchar(450)

Мы обновляем нашу кодовую базу с EF6.2 до EF Core 2.2. Наша команда обнаружила, что значение по умолчанию ключа идентификации на основе строки будет генерировать столбец первичного ключа с

  • nvarchar(128) в EF 6.2 (SQL Server)
  • nvarchar(450) в EF Core 2.2 (SQL Server)

В чем причина этого решения?


c# entity-framework ef-core-2.2
person Kuroro    schedule 22.08.2019    source источник
comment
Похоже, что дело в провайдере больше, чем в EF   -  person TheGeneral    schedule 22.08.2019
comment
Допустим, вы получили ответ на свой вопрос - чем это вам поможет? Другими словами, я думаю, что это проблема XY (meta.stackexchange.com/questions/66377/what-is-the-xy-problem).   -  person mjwills    schedule 22.08.2019
comment
В базе данных сервера sql не разрешено создавать уникальное ограничение для столбца с типом nvarchar (max). Он должен быть ограничен некоторым числом, кто-то раньше выбирает nvarchar(128), затем кто-то переходит на nvarchar(450). Я понял, что это должно быть какая-то причина, но я не знаю. Просто любопытство разработчика   -  person Kuroro    schedule 22.08.2019

Ответы (2)


arrow_upward
11
arrow_downward

SQL Server позволяет индексировать до 900 байт. Символы в nvarchar занимают 2 байта. 2 * 450 = 900. Мы (команда EF) беспокоились о первичных ключах в нескольких столбцах в EF6. В EF Core мы поняли, что индексируются только указанные символы («var» имеет разную длину), поэтому мы можем довести все до 450, и это все равно будет работать до тех пор, пока общее количество символов во всех столбцах в ключе будет меньше 450. .

person bricelam    schedule 22.08.2019

arrow_upward
0
arrow_downward

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

Что касается Почему? В то время это было проектным решением разработчика. Это также будет зависеть от того, как давно это было реализовано и была ли база данных изначально создана до того, как была реализована Entity Framework или действительно была реализована .Net.

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

Можно было бы добавить целочисленное поле Identity, а затем установить его в конфигурации как идентификатор, который будет использовать Entity Framework:

// Set Id Property as Key Property for all entities
            modelBuilder
                .Properties()
                .Where(p => p.Name == "Id")
                .Configure(p => p.IsKey());
person Mark Redman    schedule 22.08.2019