SiemarglПп 1-4 выше это только примитивный случай, а для упомянутой тобой 4НФ, потребуются новые таблицы, реляции, ключи, индексы, права итп

Естественно. Связи, индексы, ограничения, аннотации, всё создаётся. Права это совершенно другая история. И проекции они всегда только на чтение, без исключений.

SiemarglИ нормальная БД с космической кармой будет только после прогона 100% тестового покрытия, что БЛогика не поломалась от изменений. А блекаут - хуже всего. Даже перегенерить базу из ES на несколько TB будет просто местами невозможно - бизнес неделю ждать не будет.

Бизнес-логики в БД нет. Проекции только для чтения. При использовании DDD/CQRS логика в командах, и она работает с агрегатами, обращаясь к проекциям только для чтения всяких сводных данных.

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

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

И т.д. Разделяй и властвуй.

SiemarglОК, чем ES лучше чем ESB? Или классической схемы - поменяли, подгрузили....

ES это данные, история изменения всех данных вообще. А ESB это архитектура коммуникации. Поэтому их нельзя сравнивать. Вы можете и то и другое использовать.


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

Вас никто не заставляет и не обязывает. Однако преимущества микросервисов давно очевидны многим. Но чудес не бывает, конечно, за всё нужно чем-то платить.

iOracleDevДобавить поле на системе не находящейся в эксплуатации конечно никаких проблем, а вот на продуктовой каждый чих выполнять в технологическое окно как то не комильфо и перекомпилировать возможно придется некоторые объекты и кто будет переписывать логику работы бэк и фронт-энда под использование нового поля и нового алгоритма работы?

Это совершенно другой подход к разработке ПО.

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

Вы не добавляете "поле" строго говоря. Вы изменяете мета-модель, добавляете в бизнес-сущность характеристику, связь, поведение и т.д. Появление поля в БД это детали реализации, не суть и не самоцель. Но решает многое.

iOracleDevИ как эта замечательная система переварит таблицу товаров в которой много разных типов товаров у каждого типа по 200-300 свойств?
Вот пример Стиральные машины
У утюгов будет другой набор свойств, у телевизоров третий и т.д., и каждый тип товара еще не просто тип, а иерархическая классификация

Да не вопрос. Если вдруг для какой-то конкретной приложения стал удобен именно EAV-подход, например, атрибуты товаров не несут никакой бизнес-логической нагрузки кроме поиска/фильтрации, можно вообще вести проекцию для таких сущностей в ElasticSearch, а не в РСУБД -- нафига они там? Собственно, вы даже можете сделать EAV-проекцию.

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

Здесь вам удобно 4нф, а здесь сотни атрибутов для поиска, положу их в поисковое NoSQL хранилище, здесь требуется денормализация, а здесь историчность...

И т.д. и т.п.

L_argoНе суть. В крупном универсальном магазе список свойств товаров будет десятки тыщ. Если не сотни.
Интересно было бы посмотреть на этот кошмар из проекций и новых полей и таблиц.

Пояснил выше.

L_argoКак это будет выглядеть в реале ? Тысячи таблиц и полей ? Возможную связь между свойствами считаем некритичной.

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

Или в вашей реальности десяток таблиц и десяток полей -- предел, который вы вообще видели? :)

L_argoПЫСЫ: Все равно разумное решение будет одной из разновидностей ЕАВ. Просто ему дадут более заумное название. :)

Речь шла о том, что вы берёте микроскоп и забиваете им гвозди.
Т.е. берёте РСУБД со всей мощью ведения таблиц и ОЦ, и вхерачиваете туда тупой и кривой EAV, потому что не осилили современные подходы к разработке, не осилили инструмент и не поняли его смысла.

iOracleDevhVosttЭто совершенно другой подход к разработке ПО.

Если вы выбрали принцип динамического моделирования, то высшую бизнес-логику вам придётся тоже выносить в динамику. Всё становится сложнее в разработке на порядки, чудес не бывает, говорил уже.
Сложность на порядки выше, значит и поддержка на порядки сложнее и что то мне подсказывает с производительностью будут ооочень большие проблемы, так куда это можно прикладывать?

Сложность разработки подобной системы. Разработав её, вы получаете профит в чистом виде.
Но вот это сложность на старте и пугает многих.

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

Иначе, нафига бы это всё было нужно :)

iOracleDevс производительностью будут ооочень большие проблемы

Как раз об этом я и писал, в этом суть и соль.
С производительностью проблем нет, так как данные хранятся максимально эффективно.
Плюс, есть возможность вести любые проекции под задачи, в том числе денормализованные, что является просто вышкой с точки зрения производительности, быстрее уже некуда для РСУБД, когда данные у вас разложены в табличках и по типизированным колонкам с правильными индексами.

L_argoСлушай, в реальном проекте тысячи таблиц и у некоторых сотни полей. СУБД собственно и создано, чтобы эту задачу решать и решать её эффективно. Если уж на то пошло, не знаю чего вас тут смущает или пугает.В данном случае речь только про Товар и его свойства. Это большой проект ? Нет.

Продолжаете отвечать уклончиво.

Вообще не понимаю про что вы говорите, чё вы хотите, вопрос можете конкретный задать?

L_argohVosttВообще не понимаю про что вы говорите, чё вы хотите, вопрос можете конкретный задать?Вопрос все тот же: как это выглядит физически ? Товаров сотни тыщ. Видов характеристик товара десятки тыщ. Интересует хранение характеристик. Новые должны добавляться сразу, т.е. в бизнес-время. Никаких технологических окон.

Вы заставляете меня повторяться, что означает одно из двух: вам либо пофигу на ответ, либо у вас проблемы усвоением информации.

Всё зависит от задач.

Если у вас характеристик у одной сущности "десятки тысяч", что означает, что вы тупо натягиваете слона на уши в своих утверждениях, при этом выглядите довольно глупо. Зачем? А если характеристик больше чем данных? Например, пару миллионов, чё тогда? А ещё характеристики создаются/удаляются/изменяются чаще, чем данные... Дурачка может перестанем включать?

iOracleDevА где реализована бизнес логика? Если у вас была некая череда событий и нужно что то получить из начала ветки изменений, то вам придется восстанавливать всю ретроспективу, т.е. итеративно по частям, что не может быть быстрым. Опять же, пользователи изменяют данные в таблице в которой сотни миллионов записей, ddl не выкинув пользователей вы сделать не сможете, как работает ваша система на БД находящейся в эксплуатации?

Бизнес-логика реализована на DSL, на некотором количестве концепций (workflow, бизнес-задачи, бизнес-обработчики...).

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

Изменение мета-модели редко производится на активной БД, для этого существует либо теневая, либо система на отдельной среде. Потом изменения переносятся в виде последовательности событий в поток мастер данных событий. Заметного влияния на пользователей это не оказывает.

iOracleDevhVostt,

Слишком красиво в теории, нужно видеть на практике, судя по тому что такой подход не распространен, там есть большие проблемы.

Проблемы безусловно есть, но они не связаны непосредственно с самим подходом.
Методология DDD + CQRS + Event Sourcing довольно широко применяется.
Но в связке с динамикой не часто, так как это отдельный класс решений, и далеко не под все задачи подходит. Основной кейс применения это enterprise, с большим количеством справочников, реестров, процессов, постоянно изменчивые бизнес-процессы.

L_argoЗачем так грубо передергивать ? Речь о списке всех возможных характеристик всех товаров.

Хера се, "передёргивать". Покажите хотя бы один пример, где есть тысяча атрибутов у сущности, не говоря уж о десятках тысяч.

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


L_argoНабор х-к может быть произвольный для каждой карточки товара. Что тут не ясно ?

Я уже сказал, по количеству атрибутов мы упираемся только в ограничения РСУБД на количество колонок, если говорить о авто-генерации 4НФ проекции. В MS SQL там предельное ограничение до 30 тыс. колонок.

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

И микроскопом можно себе ногу сломать, зачем вот эти тупые набросы, оторванные от реальности?


L_argoГде нибудь может храниться список допустимых комбинаций (чтобы не было мегапикселов у чайника и литров у мобилки). Но это несущественно.

Это существенно. Видно, что вы не понимаете задачу, не задаётесь вопросом, какая задача и проблема решается. А я говорил про решение, для магазина нужен другой подход по крайне мере в части хранения атрибутов товаров, РСУБД плохо подходит.

iOracleDevhVostt,

Примеры коммерческих продуктов для энтрерпрайза есть?

Есть реальные внедрения на федеральном уровне, в разработке которых я принимал основное участие. А как коммерческий продукт не продаётся и не выпускается, в этом нет смысла.

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