Является ли управляемый моделью данных идентификатор ресурса аспектом ресурса или базы данных?

Question

В моих примерах будет использоваться псевдо-код C # для обсуждения, но это не относится к каким-либо отдельным языкам или инструментам баз данных.

Возьмем простую модель

Customer { string Id }

Используя RavenDB, когда я сохраняю new Customer(), он сгенерирует для меня идентификатор во время выполнения, предположим, "Customers / 234".В этом сценарии я согласен с тем, что идентификатор является аспектом RavenDB.По сути, это абсолютно ничем не отличается от Guid.NewGuid().ToString(), поскольку создает идентификатор, который не имеет человеческого понятного значения и просто достигает цели глобальной уникальности (для этой базы данных).Возможно, это просто более приятная версия руководства, и она создаст лучшие URL-адреса и позволит человеку сообщать свой идентификатор, если это когда-либо понадобится, намного проще, чем строка из 16 случайных шестнадцатеричных символов.

В другом сценарии используйте:

User { string UserName, string Id }

В этом сценарии я хочу поместить истинное семантическое значение в мой идентификатор, а не просто в уникальное число.

С RavenDB это может быть выполнено аналогично:

store.Conventions.DocumentKeyGenerator = (entity) => 
{
   User user = entity as User;
   if(user == null)
      return  defaultKeyGeneration (entity);

  return "Users/" + user.UserName;
}

Который затем во время этой операции хранилища вы получите "Users / dotnetchris"

Я также мог бы подойтиэто вместо того, чтобы пользователь имел простое свойство для Id, чтобы использовать свойство только для чтения:

User {
    string Id { get { return "Users/" + UserName }

Мне трудно решить, какое из них является подходящим местом для этой конструкции.

Я склоняюсь к тому, что он должен быть включен в класс напрямую, так как это дает вам информацию о том, что будет легко загрузить этот объект по идентификатору из пользовательского ввода без необходимости запрашивать базу данных, чтобы найти Users.Where(user.UserName == "dotnetchris")

Answer 1

Кажется, это сильно зависит от того, как данные могут или не могут быть ссылки в базе данных.Если «полный» идентификатор (т. Е. Users/name) требуется для какого-то ограничения в дизайне базы данных, то лучше держать его близко к базе данных, но если это не так, вы получите больше пользы от сохраненияэто как часть модели предметной области, обеспечивающая гибкость кода (в соответствии с окончательным примером кода).

Answer 2

Как правило, я стараюсь, чтобы каждый идентификатор принадлежал приложению, а не базе данных.Единственная причина, по которой я передам право владения идентификатором модели, - это соображения производительности, например таблица SQL, которая должна быть реплицирована и имеет 500 миллионов строк.