Возможный недостаток UserID, являющегося строковым типом в ASP.NET Identity - PullRequest
Новая
       8

Возможный недостаток UserID, являющегося строковым типом в ASP.NET Identity

0 голосов
/ 20 октября 2018

Разрабатывал приложение, которое автоматически обрабатывает аудит.

Многие из моих моделей EF наследуют FullAudited класс. 

public class FullAudited<TPrimaryKey> : Entity<TPrimaryKey>, IFullAudited, ISoftDelete
{
    public DateTime CreationTime { get; set; }
    public string CreatorUserId { get; set; }
    public DateTime? ModificationTime { get; set; }
    public string ModifierUserId { get; set; }
    public DateTime? DeletionTime { get; set; }
    public string DeleterUserId { get; set; }
    public bool IsDeleted { get; set; }
}

Видите, у нас есть CreatorUserId, ModifierUserId, DeleterUserId.

Представьте себе ситуацию, в которой приложение работает годами, и у нас есть множество записей в базе данных - каждое из этих полей содержит строку GUID, такую ​​как 5a7618ee-d279-4df9-9fe0-23f7df3053bd.

Мы могли былегко переключаться с String на long, конечно, но я думаю, что есть веская причина, почему Microsoft разработала его так: String.

Так что если мы оставим UserID как String - для такого приложения, безусловно, потребуется значительно больше памяти .

Похоже, тип по умолчанию не соответствует нашим потребностям, верно?

1 Ответ

0 голосов
/ 20 октября 2018

Я не знаю о причине Microsoft, и я не видел формального обоснования этого выбора, но мы можем сделать обоснованные предположения.

Когда вы разрабатываете библиотеку, такую ​​как личность, вы хотите самый простой иНаиболее распространенные варианты использования должны быть максимально просты в настройке.Одним из распространенных вариантов использования является миграция существующей пользовательской базы в личность.Ваши существующие пользователи могут иметь int, long, guid или string в качестве основного ключа.Поэтому наиболее надежное значение по умолчанию - это выбрать string для первичных ключей для поддержки всего.

Теперь это значение по умолчанию не подходит для некоторых пользователей, я перефразирую ваш пример:

Если у нас есть таблицапользовательских действий, в которых внешний размер string таблицы пользователей доминирует по размеру строки, тогда мы могли бы рассмотреть вопрос о выборе меньшего первичного ключа для таблицы пользователей.

Я буду считать, что менее распространенным (иболее продвинутый сценарий, чем люди, желающие перейти на Identity, и я согласен с теми, кто принял это решение.

Тем не менее, я лично изменяю на int или guid PK в зависимости от проекта, так кактакже уменьшит размер всех индексов, содержащих UserId

...