Приветствую заглянувших.

Суть проблемы - нужно переписать сервер.

Имеется - один сервер, который принимает данные у многих клиентов. При определённых условиях запускаются процессы, общающиеся с клиентами через сервер.

Как сделано сейчас:
В БД имеется таблица приходящих данных и отправляемых.
Сервер пишет в таблицу приходящих и отправляет данные из таблицы отправляемых.
Процессы соответственно из БД берут приходящие данные, обрабатывают и записывают в другую таблицу данные на отправку.

Так и живут. Данные передаются в HEX'ах.

Собственно вопрос - как лучше сделать, или мб лучше ничего не менять? Опыт в серверонаписании минимальный.

Я пока вижу варианты:
1) оставить как есть, разве что вместо HEX'а блобы использовать.
2) оставить как есть, только убрать БД и использовать другие способы передачи данных - сервер знает все процессы и необходимые им данные может посылать напрямую. (сокеты, пайпы)
4) убрать процессы, переложить обработку на сервер. Но в таком случае теряется надёжность сервера :/

PS и если кто знает, накидайте литературу по этому направлению (не общую теорию, а именно сервер и разделённые процессы обработчики).

Заранее спасибо.

"Работает - не трожь"... Суть проблемы непонятна... Скорость не устраивает? Криво работает?

Настолько криво, что проще переписать заново? Что падает-то сервер или процессы?
Не имея конкретики, я бы убрал БД как средство обмена информации и "законсолил" те самые "отдельные" процессы.

Так и я пока не пойму - насколько имеется готовность (и необходимость) в переделывании всего и вся.
Обмен информацией через БД заменить на стандартный для консолей ввод/вывод через stdin/stdout, если данных много, то можно через файл передавать, можно через QSharedMemory, можно через QLocalSocket - вариантов 100500, каждый со своими плюсами/минусами.
Если раздражают "консольные окна" (это же сервер, кто на них смотреть-то будет?) запускай их в "спрятанном состоянии".
Если же надо переписать все с нуля (а надо ли?), то вместо внешних приложений сейчас принято держать пул потоков, которые будут исполнять то, что раньше делалось снаружи. На Qt это реализуется через, например, QtConcurrent. Такое решение будет более монолитным и, теоретически, более быстрым (если таких задач много), но более сложным с точки зрения архитектуры и, как ты справедливо и сам отмечал, менее надежным.