Огромное спасибо!

court, Apache Kafka "...Одной из особенностей реализации инструмента является применение техники, сходной с журналами транзакций, используемыми в системах управления базами данных" (сразу оговариваюсь "только что-то слышала")?

Спасибо, поняла

Тогда клиент должен быть реализован как фоновый процесс, готовый всегда откликнуться. Между СУБД и этим фоновым процессом брокер собщений, который обменивает в транзакции. Не принятые сообщения возвращаются поставщику (СУБД) и передаются снова до удачной транзакции.

court, я уже согласна, что против клиент-серверной природы лучше не идти. Пусть будет серверу - серверово, а клиенту - клиентово :). И регулярный опрос таблицы будет самым дешевым и простым варианатом. Но, PostgreSQL я посмотрю ...

Спасибо за советы !

Ennor Tiegael, добрый вечер! Я согласна :)...

Ну, вот мои рассуждения на это:

Хотя у таблиц In-Memory много ограничений и пока не могу сказать, какие из них могут все испортить, можно поступить так: таблица в памяти + триггер на INSERT (не нашла нигде, что DML-триггеры в таких таблицах не разрешены)-->он передает выборку (не более 30 строк) в хранимую процедуру, а там по ней пройтись курсором и сформировать план развозки--> отправить его куда надо...
В этом случае и посредника никакого не нужно. Все решается в одном месте.

Как-то так...Что скажете?

skyANA,



Поток сильно зависит от , как говорят, гравитационных центров в бассейне маршрута.
Про пирожки написала упрощенно,т.к. не думала, что будет такой отклик.
Смотрите, может обслуживаться 30-40 пунктов причем в двух направлениях(в зависимосит от величины населенного пункта). Каждый из них может быть как источником развозки, так и приемником (кроме крайних).На каждом из этих пунктов поток заявок варьируется в течение суток. В какие-то моменты, например когда все на\с работы едут, на некоторых пунктах могут быть по 10-30 заявок в минуту в течение двух часов, в какие-то по 1-2 .
В основе алгоритма лежит матрица корреспонденций (для двух направлений, соответственно, 2 матрицы), сторится по заявкам с терминалов. Соответственно, если 30 пунктов, то размер 30*30. Составленный план должен занимать пару минут. В зависимости от алгоритма (их несколько) матрица может обрабатываться построчно либо целиком. Вчера я написала только про обработку строки матрицы из 30 элементов и в этом случае, согласна, все просто: прошелся от одного конца к другому и все получилось.
Но если нужно обработать матрицу целиком и переходы по набору могут быть в обоих направлениях разной длины, то не уверена, что курсор лучше, обработки на клиенте ...

И да...Матрицы или строки формируются как только накопилось достаточно заявок. А это значит циклы формирования и обработки могут протекать сразу же один за одним. Или даже параллельно.

Ну...Наверное, обсуждать больше нечего...Еще раз благодарю всех, давших советы. Буду пробовать. Как протестирую, отпишусь.

Пользователю aleks222 тоже дам совет на правах "тредстартерши": так участие в обсуждении дело добровольное, никто ведь не принуждает...Если вас оскорбляет уровень вопросов и рассуждений, то просто можно в следующий раз проходя мимо, проходить мимо и дальше... чтобы не осквернять свой интеллект и не расшатывать свои нэрвы, а то так и психосоматику заработать запросто...