Нормально ли для полей в базе данных чтения не появляться в базе данных записи? - PullRequest
Новая
       29

Нормально ли для полей в базе данных чтения не появляться в базе данных записи?

0 голосов
/ 12 февраля 2019

Нормально ли для базы данных записи CQRS разные поля в базе данных чтения CQRS?Например, в вышеприведенном случае нормально ли сохранение Product.Description на стороне чтения (NoSQL), но не на стороне записи (SQL Server)?

Я понимаю, что база данных является предпочтительнойна стороне записи (RDBMS) может структурировать данные иначе, чем база данных выбора на стороне чтения (NoSQL).Я специально спрашиваю, разрешено ли ему выбирать, какие поля данных сохраняются на стороне чтения и на стороне записи.

Причина, по которой я спрашиваю, состоит в том, что книга, которую я читаю, подразумевает, что это нормально, однакоЯ не могу найти в книге или в Интернете примеров, подтверждающих это.

Пожалуйста, см. Код ниже: 

public class Product
    {
        public Guid Id { get; set; }
        public string Code { get; set; }
        public string Description { get; set; }

        public void LookupDescriptionByCode(List<ProductDescriptionLookup> productCodes)
        {
            Description = productCodes.Find(x => x.Code == Code).Description;
        }
    }

1 Ответ

0 голосов
/ 12 февраля 2019

Нормально ли для базы данных записи CQRS разные поля в базе данных чтения CQRS?

Обычно база данных записи представляет собой расширенный набор данных (больше, чем) базы данных чтения.

это нормально для Product.Description, которое сохраняется на стороне чтения (NoSQL) но не на стороне записи (SQL Server)?

Нет, но, может быть.

Если вы представляете систему с монолитной базой данных записи, то «книга записей»"будет база данных записи, и все будет жить там;база данных чтения была бы просто кэшированными копиями информации в базе данных записи.

Но если бы вы разбили этот монолит, модель чтения могла бы объединить информацию из нескольких моделей записи.Таким образом, модель записи может знать только о коде продукта, но модель чтения может иметь описание продукта (потому что она использует код для поиска описания «откуда-то еще»).

Но где-то в системе у вас есть официальная копия того, что представляет собой код продукта в любой момент времени.

У меня есть журнал событий, который является книгой рекордов.Я запутался, зачем нужна база данных записи.Я вижу преимущество сохранения определенных объектов домена в базе данных записи, но не все ли они?

Если вы выполняете поиск событий, то ваш журнал событий обычно хранится в вашей базе данных записи (которая может быть СУБД или выделенным хранилищем сообщений).

Справедливо ли говорить, что если есть EventStore / EventLog / IntegrationLog, тогда база данных записи (реляционные таблицы для каждого объекта домена) не нужна.

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

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

...