Идея-то хорошая. Но в реальности оказывается, что бизнес-процессы друг от друга не независимы и оперируют одними и теми же сущностями зачастую. Т.е. БП А хочет изменять сущности 1 и 2, а БП Б хочет изменять сущности 2 и 3, причем процесс может быть достаточно сложным и не подразумевать конкурентный доступ к сущностям, например, прочитать текущее состояние сущности, в зависимости от него сделать ту или иную логику, изменить сущность. Конкурентность разных БП, которые могут получать доступ к одним и тем же сущностям, достаточно мешает подобным идеологиям, особенно есть в БП есть различные условия на модификацию сущностей

а можно рисунок фотографии скриншота?

Ты имеешь в виду, что сложно подобрать для них общую структуру, с другой стороны и отдельную на каждый БП поддерживать сложно?

Привет

11/10! Как твои, Гриша?

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

Так эт невозможно

че ваще ета структура значит

стоп лосы

Эх

TIL: если в постгресе вставить в две таблички по несколько десятков тысяч строк, а потом сразу же сделать select + join между ними (по части первичного ключа) - потсгрес может не успеть проанализировать таблицу, запрос пойдет по неправильному плану и вместо 1 секунды будет выполняться 10 минут. Решается analazy table перед селектом. Как же оракл развращает...

@catostrophe величие?

@catostrophe помоги

декомпозируй

ты можешь результирующую таблицу стразу строить при вставке?

Ну это лишние данные, они мне нужны только чтобы их один раз вычитать. А вот хранить данные в изначальных таблицах надо.

Там ещё и вакуум придется делать руками чтобы от мусора избавляться

все зависит от объема

СДЕЛАЙ КЕШ

хотя если ты атчами вставляешь можно и аналайз делать