hVosttSiemarglЯ тут пример придумал.

1. Жила была в базе 10лет сущность Сотрудник с полем Зарплата.
2. После некоторых изменений бизнеса база изменилась. Теперь у Сотрудника есть Зарплата и Премия.
3. После очередной итерации Базовый_оклад, Премия_за_выслугу_лет, Штрафы, Прочие_выплаты

Другие связанные таблицы тоже менялись несинхронно с этой.

Приходит Нач.кадров и говорить - а скажите мне среднюю Иванова за последние 10 лет!

Как это на практике будет выглядеть на CQRS, Event Sourcing ?

1. Есть сущность Сотрудник. В БД она может лежать в любой форме, какой захотите -- это проекция. Для удобства мы вели авто-проекции в 4нф, на этом строилось много запросов и логики работы с данными на чтение, плюс BI.

2. Поменялась сущность Сотрудник, добавлено поле, в связи с этим в проекцию 4нф добавлено поле в соответствующей таблице, автоматически.

3. Тоже самое.


Никакие таблицы не могут менять "несинхронно", так как их никто руками не меняет. Руками DDL запрещены, только через механизм проекций.

Поэтому мимо. Это ж ES.
Не понимаю, что в этом контексте значит "проекция". С одной стороны - БД, а с другой ?

А вопрос был - как сквозь проекции различных версий строится сквозной запрос к исторической базе "скажите мне среднюю зрп Иванова за последние 10 лет!"
1.2.3 это были условия а не вопросы

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

hVostt,

Ок, остался последний вопрос и я его не прятал
>Не понимаю, что в этом контексте значит "проекция". С одной стороны - БД, а с другой ?

softwarerSiemarglА вопрос был - как сквозь проекции различных версий строится сквозной запрос к исторической базе
Мне кажется, у вас идёт недопонимание терминологии. Суть подхода ES в том, что есть один поток событий - например "сотрудник устроился на работу", "сотруднику назначен оклад", "сотруднику выплачена зарплата" и так далее - столько, сколько придумаете, на каждый важный вам чих. Дальше из этого общего потока создаются любые нужные представления - например "сотрудники", "выплаты", "зарплаты" и так далее. Всё это живёт, добавляете новые события, правила их раскидывания по существующим представлениям, новые представления. И "средняя зарплата Иванова" в результате считается примерно как


Именно так, не понимаю.
Т.е у нас хранится _в базе данных_ "поток событий", а не нормализованные данные проекций, так?
И Выплаты_Зарплат это что то типа мат.вью или процедуры, которая пишется на каждый требуемый запрос.

Собственно, я тогда плохо понимаю, как в РСУБД хранить этот самый "поток событий"

И собственно, как отслеживать актуальное соответствие этой Выплаты_Зарплат, когда по моему примеру добавилось поле "Премия". Запрос не сломается (не будем о сложном типа Оракловых пакетов)

hVostt.....SiemarglИ собственно, как отслеживать актуальное соответствие этой Выплаты_Зарплат, когда по моему примеру добавилось поле "Премия". Запрос не сломается (не будем о сложном типа Оракловых пакетов)

Добавление поля Премия влияет на логику. Однако вы можете предупредить подобные шатания, создав проекту, где в проекцию будет писаться фактические выплаты с учётом всех ЗП, премий, надбавок, за вычетом налогов и прочего прочего прочего. Тогда вы можете никогда не париться с запросом, он у вас не изменится.
В моем примере изменения происходят со временем, по требованиям бизнеса, так что заранее бы не вышло.
И значит, что проблема отслеживания бизнес логики остается и плохо автоматизируется.

В общем за ликбез с Александром спасибо, только я не понял......А какая выгода по сравнению с EAV?

Ведь при каждом изменении будут меняться проекции (структура проекционной БД), бизнес логика, и это все потребует массовой переливки и трансформации данных, версионирования приложений, блэкаута на это все итп.

А в случае с EAV таких проблем нет.

softwarerSiemarglА какая выгода по сравнению с EAV?
Это немного странный вопрос. Примерно как "а какая выгода от танка по сравнению с дизельным мотором?" Это понятия из разных категорий. EAV - это формат хранения данных, а ES - архитектура построения информационных систем. ES вполне может использовать EAV, скажем, для представления того же самого потока событий - как танк может использовать дизельный мотор - но их странно сравнивать. Это наверное к первоисточнику, который противопоставлял.
21944256
softwarerSiemarglВедь при каждом изменении будут меняться проекции (структура проекционной БД)
Наоборот. Идея в том, что все, кто пользуется проекции Выплаты_Зарплат, вообще не заметят, что зарплата развалилась на зарплату и премию. То есть, приложение, которое считает "среднюю зарплату Иванова" так и будет выполнять вышеописанный запрос и получать верный результат, как бы ни менялась логика начисления этой самой зарплаты.Не поменяется, только если у приложения была функция Суммарная_выплата, а так API поменяется - чтобы отражать все новые данные.

Я вообще не вижу каких то принципиально новых идей в ES %-/

Кажется лет 30 изобрели Enterprise Servise Bus и это одна из простейших реализаций

softwarerSiemarglЭто наверное к первоисточнику, который противопоставлял.
Я помню, что hVostt их противопоставил, и не был в восторге от той реплики, хотя и понял, что он имел в виду. А я не понял. И в свете ваших обоюдных уточнений хотелось бы понять, чем мое непонимание противопоставления, упомянутое здесь 21962820 отличается от высказывания Хвоста, которое внезапно, оказалось понятным.
softwarerSiemarglНе поменяется, только если у приложения была функция Суммарная_выплата,
Не "функция Суммарная_выплата", а "проекция Зарплата". Вы, когда говорите о расчёте средней зарплаты, имеете в виду некое понятие "Зарплата". Немного виртуальное в том смысле, что не продумываете чётко, как оно рассчитывается. Выше я упомянул про аванс и собственно зарплату - как раз поэтому. Когда Вы говорили про расчёт средней зарплаты, Вы наверняка имели в виду их сумму, но явно об этом не говорили и не думали. И эта архитектура позволяет именно так и действовать - завести проекцию "Зарплата" а дальше уточнять это понятие, формировать его из белой, чёрной и серобуромалиновой, используя при этом независимо от уточнений.
Siemarglа так API поменяется - чтобы отражать все новые данные.
API останется прежним - та же проекция в виде реляционной таблицы. Поменяется скрытая от приложения логика её наполнения. Может быть, API дополнится - появятся новые проекции или новые атрибуты в той же проекции. А поменяться так, чтобы потребовалось менять старые приложения - сравнительно редкая необходимость. Скорее даже не необходимость вообще. Нет, я думал не так. Я как раз думал, что Зарплата распадается и далее становится агрегатом от разных опций. Аналогично Биллингу с кучей опций от фазы луны, например. И невозможно поддерживать старыми функциями новые расширения. Но скорее, что поменяется структура проекционной базы со всеми вытекающими
....

hVosttSiemarglА в случае с EAV таких проблем нет.

Пишу с телефона, поэтому процитирую маленький кусочек.

Нет есть, и они просто огромные, колоссальные

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

Теперь наше решение на ES.

1. Добавляете новый атрибут в метамодель.
2. Создаётся событие добавление атрибута
3. Подсистема проекций ловит такое событие с создаёт колонку. При чем not null тоже допускается со значением по умолчанию
4. Далее в колонку с новым атрибутом будут писаться значения.

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

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

Пп 1-4 выше это только примитивный случай, а для упомянутой тобой 4НФ, потребуются новые таблицы, реляции, ключи, индексы, права итп
И нормальная БД с космической кармой будет только после прогона 100% тестового покрытия, что БЛогика не поломалась от изменений. А блекаут - хуже всего. Даже перегенерить базу из ES на несколько TB будет просто местами невозможно - бизнес неделю ждать не будет.
hVosttSiemarglЯ вообще не вижу каких то принципиально новых идей в ES %-/

Ну я даж незнаю, это как вообще можно их не видеть?
А мы ведь даже ещё не говорили про микросеовисы, только одну тему затронули про нормализованное хранение данных.
ОК, чем ES лучше чем ESB? Или классической схемы - поменяли, подгрузили....

А микросервисы - отдельная тема. Отрыжка теоретического ФП, которые на практике (а не на бумаге) в затратах стоят дороже выгоды.
Только если придумать идеальный фиксированный интерфейс обмена......Иначе N^2-N