кучу проблем себе снимаешь тем самым

В любом случае делаешь синхронизацию в фоне. Но как это решает озвученные мной проблемы? )))

не надо нэнси, плохая это идея

почему

В любом случае делаешь синхронизацию в фоне. Но как это решает озвученные мной проблемы? )))

По-хорошему через шину/message broker, но это не решает всех проблем )))

Приглашаем вас принять участие в онлайн-конференции «Бизнес.IoT: открывая Интернет вещей»! https://blogs.msdn.microsoft.com/rudevnews/2017/03/07/join-to-online-conference-business-iot-opening-the-internet-of-things/ Приглашаем вас принять участие в онлайн-конференции «Бизнес.IoT: открывая Интернет вещей». 30 марта 2017 года, 10:00 (МСК). Концепция Интернета вещей неразрывно связывает технологии и бизнес, помогая компаниям быстрее выходить на рынок, привлекать заказчиков уникальными сервисами, повышать эффективность бизнес-процессов. Вас ждут два параллельных трека с лучшими практиками, демонстрациями, выводами и рекомендациями от экспертов в области Интернета вещей,...

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

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

когда данные проецируются 1 к 1 - это не сложно

опять же решение триггерить по базе не лучшее

забирай пачками по 1К записей и группируй номера записей, которые надо обновить

если триггерить не по базе, то получишь лапшу

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

про CQRS, ES слышал?

слышал

теперь построй на них всю архитектуру так, чтобы с ней мог работать не только ты один

а то наслушаются про акторы и журналы событий

порог вхождения никто не отменял

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

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

>то скорей всего у тебя нагрузка то скорей всего у тебя JOIN на 15 таблиц и нужен полнотекстовый поиск

и всё это ложится даже без нагрузки

денормализовать и в той же базе можно

про full text согласен

можно и на той же, но смысл

забирай пачками по 1К записей и группируй номера записей, которые надо обновить

теряешь consistency при связях один ко многим/много ко многим

не потеряешь

)))

у тебя обновления к изменившимся в следующей пачке придут

по сути в процессе синхронизации идёт генерация слепков состояния

этакий самообновляющийся кэш

почему

при всей внешней простоте с нэнси будет больше проблем чем пользы, возьми сразу asp.net core и не мучайся

>asp.net core > не мучайся

ок, пример: две сущности - продавец, товар продавца у одного продавца куча товаров каждый товар меняется отдельно, меняется информация о продавце

попробуй не получить рассинхрон не используя parent/child

причем есть вероятность обломиться при optimistic lock

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

а тут и не нужны локи

в этом вся прелесть

даже если закинешь в эластик протухшие данные

за счёт глобальной версии строки

у тебя информация об изменениях всё равно потом обработается

т. е. ты по сути идёшь по истории, формируя список номерков того, что надо перегенерить

да, на сценарии "товары привязаны к продавцу и городу, поменялись названия продавца и города" придётся два раза перегенерить товары

что даст оверхед

но это жертва, на которую я намерен пойти

ну и эластик будет всё время несколько отставать от основной базы

я всё это к тому, что нет универсального решения

и у elastic'а с сортировкой плохо

понятное дело, что головой всегда думать надо

ну и эластик будет всё время несколько отставать от основной базы

с этим ты ничего не поделаешь

ну формально можно сидеть и тупить на транзакции в основную БД, пока bulk-запрос к эластику не завершится

и получать всегда свежие данные

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

а при изменении товаров?

но тогда будет проблемы см. выше

при изменении товаров у тебя уже есть id

по которым ты точно так же последовательно идёшь

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

ну да

тут смотри в чём плюшка решения

при изменении продавца все?

у каждой записи есть уникальный номер ВЕРСИИ ВСЕЙ БД на момент её создания/изменения

а эластик умеет работать с внешним версионированием

Всем привет! Сюда новичкам с вопросами?

умеет

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

записи куда

ERROR: S client not available

в эластик

на чём

два события - обновление информации о конкретном товаре, информация об обновлении продавца - обновляем все товары

и тут как повезёт

повезёт что

у тебя более позднее событие

будет обработано позже или в рамках той же операции, что и более раннее

Всем привет! Сюда новичкам с вопросами?

задавай

будет обработано позже или в рамках той же операции, что и более раннее

с чего такая уверенность?

с того что мы бежим по записям по порядку номера версии БД

на вьюжал студио на си шарпе же можно писать не только консольные приложения но и приложения с кнопочками и окошечками? Дело в том что не представляю с чего начинается ищучение такого.

с того что мы бежим по записям по порядку номера версии БД

один воркер, последовательно?

на вьюжал студио на си шарпе же можно писать не только консольные приложения но и приложения с кнопочками и окошечками? Дело в том что не представляю с чего начинается ищучение такого.

можно)

на вьюжал студио на си шарпе же можно писать не только консольные приложения но и приложения с кнопочками и окошечками? Дело в том что не представляю с чего начинается ищучение такого.

WPF + XAML

один воркер, последовательно?

Один воркер, внутри себя параллелит формирование записей в рамках операции

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

с чего такие выводы?

"один воркер" было сказано как что-то плохое

это и так плохо

если же тебе не хватает выделенного сервера с 8 ядрами на формирование JSON-записей для эластика

при частой записи, ты в него упрёшься, и отставание будет увеличиваться

то почему ты вообще сидишь в этом чате?

как это связано?)

"один воркер" было сказано как что-то плохое

к тому же single point of failure

на нескольких воркерах будет больше оверхеда

из-за того что ты будешь генерить записи

а у эластика уже будет более свежая версия

на вьюжал студио на си шарпе же можно писать не только консольные приложения но и приложения с кнопочками и окошечками? Дело в том что не представляю с чего начинается ищучение такого.

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

не вижу особого выигрыша от него тут

нет, написание программ с кнопочками начинается с Form1

WPF + XAML

Кто-нибудь пробовал WPF software rendering на больших приложениях? Есть pet-project, который работает в условиях что нагружать видеокарту нельзя, а форму показывать надо. После WPF в WindowsForms слегка приходится страдать с некоторыми вещами.