Sergey Gladilin
Ну вот опять, ..., Вы пишете "многие задачи" и не приводите ни одного конкретного примера?

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

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

Только совмещая во времени на одном графике кривые различных потоков можно выполнять оперативный анализ исполнения технологического процесса.

Таким образом, часть информации вынимается из БД, а часть информации берется из входного потока. При этом эти данные подвергаются непрерывной аналитической обработке, для того чтобы вычислять фактическое время запаздывания входных потоков в переделах для коррекции запросов к БД.

Вот Вам один из немногих жизненных примеров.
Если ничего подобного Вам еще не встречалось, то это просто ВАМ не встречалось.

Sergey Gladilin AlexKBТаким образом, часть информации вынимается из БД, а часть информации берется из входного потока. При этом эти данные подвергаются непрерывной аналитической обработке, для того чтобы вычислять фактическое время запаздывания входных потоков в переделах для коррекции запросов к БД
Спасибо за ответ, но, к сожалению, я все равно не понял. Что из сформулированного мешает использовать реляционную СУБД? То, что одного SQL в данной задаче не хватит - понятно, ну будет написан кусок анализа на java, С++ или еще каком языке. Но дело же не только в этом? Почему данные в данной задаче выгодно хранить в MUMPS-глобалях, а не SQL-таблицах?

Я опускаю тот момент, что будут использованы не одна а ряд технологий для реализации такой задачи.
Но мне нужно точно знать что в аналитический блок попадут данные которые поступили сейчас (0 секунд назад) и те которые поступили ровно 346 (786) секунд назад.

a(0)=b(-0) + c(-346) * d(-786)

Это самое простое аналитическое выражение. Индексы означают запаздывание от момента текущего времени. Запаздывания не статичны. Выражений вычисляется одновременно от десятков до сотен. Все они разные и оперируют с некоторым количеством разных переменных (скажем 300). Результаты работы будут складываться в БД и будут извлечены либо сразу же, либо по истечении какого-то времени. Все обработки должны быть пакетированы, т.е. до приема следующей порции информации необходимо выполнить всю аналитическую обработку, передать результаты в БД, выдать обработанные пакеты в систему отображения, заполнить протокол реального времени (построчная печать) и выдать в процесс печати, на сновании обработанных данных выдать управляющие воздействия во внешние устройства. Все это должно происходить строго 5 раз в секунду (а в моем случае это было 20 раз в секунду) и в строгой последовательности.

Простите, совсем забыл

Sergey Gladilin Но дело же не только в этом? Почему данные в данной задаче выгодно хранить в MUMPS-глобалях, а не SQL-таблицах?

Да простят меня MUMPSисты за упрощение.

set Time=текущее время в секундах

set ^a(Time)=^b(Time-0) + ^c(Time-346) * ^d(Time-786)

где:
^b(Time-0) взял из БД текущее значения параметра <b>

^b(Time-0) + ^c(Time-346) к нему прибавил значение параметра <c>, но которое было сохранено в БД (получено от устройства измерительного) 346 секунд назад

^b(Time-0) + ^c(Time-346) * ^d(Time-786) сумму умножил на значение параметра <d>, но которое было сохранено в БД (получено от устройства измерительного) 786 секунд назад

set ^a(Time)=^b(Time-0) + ^c(Time-346) * ^d(Time-786) вычисленное выражение сохранил в БД по текущему времени


И никаких тебе критилок с таблицами в виде SELECT...... WHERE...

А то тут некоторые все возмущаются по поводу циклов и ничего не говорят о том что SELECT это уже неявный цикл.

mumps-истЕсли по времени построен B+ Tree индекс, то выбор записи будет осуществлен проходом по дереву без всяких циклов - также как и в Cache.

В Вашем случае это проход по дереву, а в моем это переход на конкретную ветку. Хотя не берусь обсуждать именно этот вопрос, поскольку тут детали реализации. Пусть этот вопрос обсуждают специалисты производителей систем, а не прикладные программисты. Это будет правильней, а нам предоставят результаты сравнительного анализа и свои доводы в пользу своих технологий.

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

Да, действительно существует много языков и средств. Но этих средств будет как минимум три, на практике где-то пять. А тут одно средство, которое, кстати, интегрирует в себя языки и средства. В этом случае нет необходимости искать опытных программистов, достаточно рядовых. Да и не только Москва присутствует на земном шаре, есть и еще города с меньшим уровнем оплаты специалистов, причем по вине Мсквы (это мое личное убеждение и прошу его не обсуждать на этом форуме).


mumps-ист2. Используя mumps вы отказываетесь от хороших средств разработки, отладчика, profiler-а, встроенного контроля версий, нормального ООП - либо вынуждены писать сам всяческие плагины для IS Studio.

А это еще вопрос, если в отладочных средствах Cache мало бантиков и рюшечек, то это не умаляет возможностей. Я например могу мониторить исполнение каждой команды в теле программы и выкладывать в логи любую информацию доступную текущему процессу. При этом другой процесс может тут же по ходу анализировать этот лог и делать соответствующие выводы. При этом еще какой-то процесс может быть переведен в пошаговый режим и отлаживаться на удаленном рабочем месте. А вот содержимое регистров центрального процесса видеть не могу, это правда.

mumps-ист3. При создании нормального Win32 GUI ( если вы уж хотите в реальном времени что-то отображать) mumps заканчивается и все равно начинается использование других технологий. А вот их интеграция с mumps при использовании глобалов - это еще та радость.


Да, действительно очень сложно прикладному программисту написать
Set Form1.TextBox.Text=^Arhiv(data,smena,operator) // показать фамилию текущего оператора установки.

Sergey Gladilin
А поясните пожалуйста, что имеется в виду? То, что MUMPS позволяет реализовывать Win32 GUI или то, что MUMPS легко интегрировать в другие технологии? Если второе, то как это реализуется? Из каких языков могут быть доступны глобали MUMPS?

Я работал с реализациями MUMPS, которые имели встроенный Win32 GUI, также знаю что разработчики пользовательского уровня писали свои собственные инструментальные средства и легко их интегрировали с MUMPS.

Но в данном случае показана интеграция Cache с Win32 GUI на уровне ООП (SMWrap). Win32 GUI занимается отдельный графический проигрыватель (Браузер можно сказать), методы в данном случае исполняется на Cache. Способ довольно-таки нетрадиционный, у него много противников. Но именно этот способ позволил достичь тех результатов, о которых я вкратце упомянул.

Параллельно решались эти же задачи на других средствах (три-пять технологий), и до сих пор решаются, но к результатам достигнутым описанным выше способом они так пока и не подошли. Хотя все у них впереди и я не берусь сказать что это невозможно, правда уровень квалификации их группы выше, чем той у которой результаты уже есть налицо.

Доступ к глобалам Cache возможен, по моему, из всех традиционных языков программирования (VB, VBA, С++...), которые поддерживают стандартные интерфейсы. Более того, доступ возможен к программам, функциям, переменным.

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

Можно я отвечу на ряд вопросов.

Sergey GladilinТак, давайте по порядку.
Скорость - имеется в виду на клиенте или на сервере? На порядок - это в 10 раз, я так понимаю?

На этот вопрос ответа конкретного Вам никто не даст, все очень относительно.
Единственно что могу сказать, что обработку программист может распараллелить по разным процессам на сервере, а если и клиент написан на Cache, то выполнив специфическую подготовку данных на сервере клиент быстрее выполнит окончательную обработку. Можно выполнять окончательную обработку предварительно подготовленных данных по мере навигации по данным.

Sergey GladilinУдобство перенастройки и обслуживания - о чем вообще речь? Перенастройка - это ведь не правка исходников? Она в конфигурационных файлах осуществляется? Какая разница, на чем система написана?

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

Sergey GladilinЛегкая интеграция - это преимущество Cache или Вашей реализации? В чем конкретно и с какими системами обеспечивается легкость интеграции?

Легкая интеграция - это особенность Cache.
Мне доводилось интегрировать с различными SCADA-системами, средами программирования. Вот правда обобщенной выгоды по целуму ряду показателей, а не по одному, я не ощутил. Ну а в чем конкретно - предствьте себе, что Вы легко и просто общаетесь с объектами базы данных, заметьте хранимыми объектами, а не существующими в контексте С++ процесса. При этом к объектам обеспечен множественный доступ.

Sergey GladilinНизкая себестоимось разработок и простота программирования на MUMPS - вот этого я вообще понять не могу. Синтаксис у MUMPS весьма необычен - выпускнику ВУЗа со знанием Си или VisualBasic этот синтаксис будет казаться странным. Откуда данная простота и дешевизна? MUMPS с Вашей точки зрения действительно настолько приятный язык?

Совсем не нужно искать дорогостоящих программистов высокой квалификации для разработки и сопровождения. По поводу синтаксиса - если выпускник учил только Си или VisualBasic, то синтаксис HTML будет куда более чем странным по сравнению с MUMPS -> Cache.
Те программисты, которые позже начинают программировать на MUMPS, чем на других языках, переучиваются очень легко, потому что необычных всего где-то пяток команд и пяток функций. Самое главное требование к таким программистам элементарная порядочность. Чтобы не спекулировали на этом вопросе.
Те программисты которые начинают прграммировать с MUMPSа, переучиваются с других профессий, очень сильно удивляются почему дипломированные программисты так не любят этот язык. А еще больше они удивляются почему это у дипломированных всегда какие-то вопросы, проблемы, нестыковки с конечным ЗАКАЗЧИКОМ и тому подобное.