и будет булшит кода гораздо больше

если у тебя есть nosql документ и тебе надо подмержить кучу полей - нен ужно делать новую сущьность

или у тебя модель данных херовая

чем если бы ты сделал builder

да любая на кучу палей не твоих данных

щас бы при парсинге тендеров я структуру менял

да любая на кучу палей не твоих данных

что нетвои данные делают у тебя?

ну сделай immutable object

действвительно

объявляй сеттеры

и генерируй каждый раз новый объект

как это предложили делать в psr response

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

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

пиши стрим событий)

пиши стрим событий)

всё равно в 1 сущьность

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

почему дорого?

нет никакого табу на сеттеры

если дорого - есть вероятность что опять же ты выбрал херовую модель данных

почему дорого?

дополнить поля дешевле чем переписать

а теперь просто ищешь себе оправдания

дополнить поля дешевле чем переписать

не всегда

почему дорого?

тем более удалить старый и записать новый в nosql без транзакций

последовательная запись дешевле рандомной

не всегда

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

тем более удалить старый и записать новый в nosql без транзакций

тебе не надо ничего удалять - append only

хорошо ложится на монги всякие

нет никакого табу на сеттеры

Нет никакова табу на goto или на рефлекшен и вызов приватных методов или свойст через рефлекшен

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

тебе не надо ничего удалять - append only

в базе с миллионом каждый день меняющихся тендеров ?) при этом дописывая а не изменяя?

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

ну или юзают аккуратненько и зная что делают

в базе с миллионом каждый день меняющихся тендеров ?) при этом дописывая а не изменяя?

да, почему нет?

ну или юзают аккуратненько и зная что делают

да

ну например потому что надо агрегацию делать та терабайтах

в базе с миллионом каждый день меняющихся тендеров ?) при этом дописывая а не изменяя?

да

ну например потому что надо агрегацию делать та терабайтах

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

ну например потому что надо агрегацию делать та терабайтах

жесткий диск дешевый ресурс

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

я и сам знаю "милилон способов" решить это без изменени

вас походу троллят, господа)

это попросту не нужно ради красоты

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

еще раз - ты пишешь агрегатор какой-то херни которая часто меняется

доменной логики там нет, так? пришло - записал. Или есть?

вас походу троллят, господа)

да мы вкурсе

так тендеры годами длятся

так тендеры годами длятся

какие нахер тендеры?

то паспорта, то тендеры

ну такие вот

либо рассказывай суть либо молчи

паспорта был про другое пример и не мой

ну так рассказывай откуда вылезли тендеры и что ты с ними делаешь

а ну аргументы подъехали )

а ну аргументы подъехали )

еще раз - есть у тебя дохера тендеров - что ты с ними делаешь?

щас бы при парсинге тендеров я структуру менял

^

просирает)

просирает)

вот

^

пришло -> распарсили -> записали в базу

так?

никакой пред/пост обработки

втупую

нет

куча пред и пост обработки

продолжай, что происходит после парсинга

во первых много страниц

во вторых связанные между собой сущьности

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

у всего свои номера без явных ссылок

п.с. сущность без мягкого знака) не впервой уже, глаз подрезает)

в заддаче сбора статистики контрагента по инн появляется куча связей

ERROR: S client not available

но это вообще не суть

вопрос в том что данные меняются

есть смысл их апдейтить

и данные не сразу приъодят а связи нужны

можешь ли ты выделить ту часть данных которая меняется и которая не меняется (может добавляться. но не меняться)

в т.ч. фильтры в глубину джоинов

в т.ч. фильтры в глубину джоинов

у тебя ж там nosql

да там чужие данные что угодно может меняться

для меня это просто стринг или набор стрингов или файл я в него даже не смотрю

дл\ кода пофигу что там за суть данных

просто сет

не пофигу только в карте имён для вывода

дл\ кода пофигу что там за суть данных

как происходит пост/пред обработка если все это просто строки?

ну то есть, если как ты выразился "хер знает что там"

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

связи делаются кодом

на этапе импорта

"статистика"

но я всё равно не вижу смысла это описывать

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

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

меня не это интересует, меня инересует флоу обработки данных

ну есть тендер какой

методы переименовать любой дурак может

это могет быть разные сайты не только официальный

с разной структурой

так

стой

вот на этом месте

есть маппинг базовых полей типа названия текста

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

обработка данных - положил стрингом в базу никаких нормализаций

город пишется как есть, например, текстом