есть еще 1хn водители

а в какой момент появляются опциональные таблицы и связи?

есть пользователь покупает полис осаго

о. Осагу кто-то нормально делает?

по ходу работы задачи

я бы сделал сагу. в стейте которой бы хранил всё сраное мракобесие. А потом, как любит @fes0r, сохранил бы всё 1 документом в jsonb. Никаких анальных связей через пол базы, чисто и красиво)

о. Осагу кто-то нормально делает?

пытаемся, у нас взр более менее сделан вот пытаемся сделать норм но там для Москвы и МО будет только

я бы сделал сагу. в стейте которой бы хранил всё сраное мракобесие. А потом, как любит @fes0r, сохранил бы всё 1 документом в jsonb. Никаких анальных связей через пол базы, чисто и красиво)

у нас ситуация в том что

апи страховых это такая жопа

что словами не описать и работают они тоже через это же место

пытаемся, у нас взр более менее сделан вот пытаемся сделать норм но там для Москвы и МО будет только

Это лютая дичь. Сам делал в свое время 2 проекта... В том числе и Осагу

апи страховых это такая жопа

я сейчас работаю с юридически значимым документооборотом и знаю о каких жопах ты говоришь))

задача не всегда за один раз выписывается и мы долбим)

тем не менее, саги - лучший выбор

по n раз или m минут)

я бы сделал сагу. в стейте которой бы хранил всё сраное мракобесие. А потом, как любит @fes0r, сохранил бы всё 1 документом в jsonb. Никаких анальных связей через пол базы, чисто и красиво)

Там беда в том, что по вот этим оплатам и етк надо бы уметь фильтровать

Тупо jsonb не прокатит

Там беда в том, что по вот этим оплатам и етк надо бы уметь фильтровать

а как строить представление - вопрос третий. Тебя никто не ограничивает

разделяй и влавствуй)

проблема в том что

пока таска не завершилась

а как строить представление - вопрос третий. Тебя никто не ограничивает

дык... там никто не скажет заранее по чему фильтровать)) А оплат и прочего постоянно и много. У меня около 150к полисов в месяц выходило на проекте

нет данных в бд а выдергивать стейт и анализировать жопа еще хуже

Это около 2 млн сущностей

а основная часть косяков происходит на этапе выписки

И фильтровать минимум по пол года

нет данных в бд а выдергивать стейт и анализировать жопа еще хуже

это для саги не проблема) это её суть)

дык... там никто не скажет заранее по чему фильтровать)) А оплат и прочего постоянно и много. У меня около 150к полисов в месяц выходило на проекте

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

Это около 2 млн сущностей

у нас по взр тоже много

есть мысль, что ты не очень представляешь себе разделение на read и write модели

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

То, что фильтрует не разраб)

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

представление задачи зависит от стадии где находится задача

представление задачи зависит от стадии где находится задача

это не проблема

на одном этапе могут быть данные на другом нет

То, что фильтрует не разраб)

ну так сделай такое представление, по которому фильтровать удобнее

трудно перестать мыслить реляционными связями...

есть мысль, что ты не очень представляешь себе разделение на read и write модели

давай подробнее. Может действительно не о том думаем

трудно говно скинутое вот в такую структуру

потом приводить к норм виду

учитывая

ну так сделай такое представление, по которому фильтровать удобнее

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

давай подробнее. Может действительно не о том думаем

у тебя есть операционная база (write модель), в которой хранится стейт твоей саги (все шаги, которая она выполнила, все промежуточные данные и т.д. Всё, что она по ходу жизни собирает для решения задачи). когда сага завершается, ты з этих накопленных данных можешь построить представление в ЛЮБОМ формате и виде. Хочешь sql - бери sql. Хочешь no-sql - пофиг. Хочешь почтовыми голубями реестры перекидывать - перекидывай

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

ну звучит как изи бризи

я просто по jsonb хз. Прощу тогда сразу в монгу представление лить и фильтровать по ней

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

а ты понимаешь о чем речь

я просто по jsonb хз. Прощу тогда сразу в монгу представление лить и фильтровать по ней

не проще

можно это сложить в монгу

конечно

да в хер монгу

или другую nosql

можно это сложить в монгу

зачем? пока у тебя индексы в память сервака помещаются постгреса хватит.

зачем? пока у тебя индексы в память сервака помещаются постгреса хватит.

а потом сгружай в архив)

у тебя есть операционная база (write модель), в которой хранится стейт твоей саги (все шаги, которая она выполнила, все промежуточные данные и т.д. Всё, что она по ходу жизни собирает для решения задачи). когда сага завершается, ты з этих накопленных данных можешь построить представление в ЛЮБОМ формате и виде. Хочешь sql - бери sql. Хочешь no-sql - пофиг. Хочешь почтовыми голубями реестры перекидывать - перекидывай

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

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

сага сохраняется всегда

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

ну как бы да, и что?

ну да надо по хорошему чистить эти данные

диск дешевая штука

после выполнения таски

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

+

диск дешевая штука

и фильтровать по незавершенным

еще есть особые данные

ну и в постгрессе есть еще такая волшебная штука как brin index-ы

по pci dss когда сертифицирован

блин... вы не слышите что ли)

и фильтровать по незавершенным

у тебя МАЛО данных, чет ты переживашеь

номер кредитки и cvv хранить низя больше чем это необходимо

ERROR: S client not available

2 миллиона сущностей...

пффф

номер кредитки и cvv хранить низя больше чем это необходимо

их аще нельзя хранить, так-то

номер кредитки и cvv хранить низя больше чем это необходимо

вообще нельзя хранить, лучше получить токен платежный и так хранить.

их аще нельзя хранить, так-то

я выше написал об этом

что там есть регламент

я выше написал об этом

ты написал не об этом)

если их не хранить в памяти то где ?)

ну короч, я так понял что вам просто поныть а не проблему какую-то решать

я написал выше ситуацию и 2 кейса для примера

никак не связанные с производительностью

ну как решить проблему я накинул. Почему проигнориои - хз, но и пофигу)

какой из этих кейсов

вы захотели детали, я вам дал детали

ты хоть проанализировал решение которое тебе @desper1989 дал?

ну как решить проблему я накинул. Почему проигнориои - хз, но и пофигу)

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

ну ок допустим сделаю я так

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

нет, сложить все в кучу когда уже все нормально.

ну как решить проблему я накинул. Почему проигнориои - хз, но и пофигу)

Да просто ты говоришь опреационку по хорошему из write в представление потом слить

реляционно id задачи (заказ) 1 x 1 страхователь, 1х1 тс

Да просто ты говоришь опреационку по хорошему из write в представление потом слить

это называется "проекция" и да, это лучше чем пытаться write и read модели унифицировать

1х1 платежка

Но тут прикол в том, что операционка по факту и нужна потом. Да. Круто. Но данных меньше не станет

заканчивайте мыслить только sql

это ж тупик...

Но тут прикол в том, что операционка по факту и нужна потом. Да. Круто. Но данных меньше не станет

а у тебя есть проблема с количеством данных?)

нет, сложить все в кучу когда уже все нормально.

я понял его ход мысли

нет, сложить все в кучу когда уже все нормально.

вот допустим у меня есть данные и по платежке

@desper1989 "Никаких анальных связей через пол базы" - а мне люто нравится эта идея!!!

и по всему

Но тут прикол в том, что операционка по факту и нужна потом. Да. Круто. Но данных меньше не станет

стрим ивентов можно хранить вообще бесконечно много, пока деньги не закончатся (и то архив можно складировать на магнитную ленту)

вот у тебя есть куча key value хуйни и надо ее сложить на хранение