Система принятия решений и/или Нечеткая логика(FuzzyLogic)

Уточнение: у меня в роботе устанавливается разрешение таймера: 1 млс.

На самом деле все совершенно иначе.
Колбек тем и хорош что его не надо ждать. Он вызывается событием.
Разница огромная если есть множество инструментов.
----------------------------
1) Например, колбек OnOrder уже содержит класс и имя инструмента. т е если состояние заявки изменилось, то получим в скрипте  уже готовую информацию об инструменте и состоянии.
Если же лазить в архив или таблицу, то сначала колбек туда поместит изменение состояния заявки, а потом функция  SearchItems (лезет в архив) или getItem (лезет в таблицу)  будет перебирать все данные и фильтровать их. Обращение к архиву не быстрая операция.  
2)  Если колбека нет, то и телодвижений никаких нет.
А при опросе архива SearchItems  это делается на каждом цикле main есть событие или его нет.  

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

Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.

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

Не против использования таблиц. сам делал робота в скрипте индикатора и там использовал именно таблицы, так как это проще и в индикаторах нет колбеков.
Вы же объясняете почему Вы так делаете. Я тоже объяснил почему колбеки быстрее работают.

Добавление к предыдущему моему комментарию.
   Иллюзией является представление о том, что коллбеки выполняются параллельно с потоком main. Код скрипта, включая функции коллбеков, разделяется основным потоком QUIK и потоком main. Это значит, что когда выполняется один, то другой блокируется. Переключение потоков происходит только при вызове активным потоком сишной функции (в которой нет автоматического управления памятью Lua). Одной из сишных функций является sleep. Также сишными функциями являются стандартные функции Lua.
 В основном потоке выполняется много чего, смотрите по ссылке: https://forum.quik.ru/messages/forum10/message74919/topic8563/#message74919.
 При обработке коллбеков основной поток может блокироваться в моменты выполнения в потоке main lua-кода. При выполнении функций коллбеков он также перестает выполнять всю остальную свою функциональность и блокирует выполнение потока main. Поэтому разработчики QUIK рекомендуют создавать между коллбеками и потоком main очереди, а сами коллбеки делать минимальными.
 В текущей архитектуре QUIK интенсивное использование коллбеков, нагружая основной поток QUIK, как описано выше, негативно влияет на его функционирование и это следует учитывать при написании скриптов.
 Я написал в ветке по ссылке (пункт 2), что можно бы было изменить в QUIK, чтобы уйти от описанных проблем. Там же, в конце, выложен конкретный вариант, как это можно реализовать, на уровне конкретного работающего кода на C++.

  Обрабатываются варианты:
1) удаления заявок;
2) реорганизация используемых таблиц по любой причине;
3) перезапуск робота с восстановлением  продолжения его работы.

  1. Я как то уже писал, что коллбек OnTransReply при выполнении  транзакций мной используется, т.к. только в нем есть полезная информация о причинах отказа выполнения транзакции.
  2. Для снятия заявки я использую два варианта: синхронный (когда роботу нечего делать)  и асинхронный.
   В любом  случае обрабатывается только снимаемая заявка а не все активные заявки.

  Это у меня обрабатывается в:

   Секрета нет.  Контроль реорганизации таблиц заявок (соответствия индексов записей их полям trans_id) я выполняю циклически (других вариантов для надежного контроля возможных мутаций этих таблиц в текущем QUIK я не вижу) с периодом в 5 сек. просмотром активных заявок кэша, ссылающегося на таблицы, и там же, заодно, увижу снятые неизвестно кем заявки робота. Задержка в 5 сек. меня пока устраивает. Не будет устраивать подключу OnOrder.