IT в России и мире в реалиях мирового кризиса

Цитата: Alexxey от 02.02.2017 15:16:26Как таковое отслеживание операций INSERT, UPDATE и DELETE – это и есть механизм триггеров. Аналоги механизма генерации событий для внешних приложений, который Вы описали, есть и в других БД. В оракле это можно осуществлять с помощью external procedures.

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

Цитата: Alexxey от 02.02.2017 15:47:46Как Вы можете это утверждать, если не знаете как это сделано в других БД.
Смотрите, для Оракла Вы пишете обычную стандартную библиотеку на удобном Вам языке C, C++, Delphi, Pascal, Java... хоть Visual Basic. Подключаете её как external library
create or replace library my_utils is '${EP_LIB_HOME}/utils.so'
или
create or replace library my_utils is 'C:\my_utils.dll'
например.
И пользуетесь функциями из неё, как обычными хранимыми процедурами/функциями
CREATE OR REPLACE FUNCTION some_func (
x BINARY_INTEGER,
y BINARY_INTEGER)
RETURN BINARY_INTEGER
AS LANGUAGE C
LIBRARY my_utils
NAME "some_func";
Вызывайте хоть из триггеров, хоть из других хранимых процедур, хоть просто из SQL.
Что может быть гибче и удобнее?

Лучше и проще - подписка на события! Потому что:
1) То что вы привели - работает в синхронном режиме, генерируя либо дополнительную постоянную нагрузку на сервер, либо постоянный сетевой трафик запросами!
2) Подписка на события - это асинхронный механизм! Выше я уже привел отрывок из книги, как это работает. А работает просто. Подписываетесь через специальный механизм на сервере один раз на интересующие Вас события и получаете их, когда они только произошли в режиме реального времени (только ответ!). А закрываете сессию асинхронно, командой отмены подписки! Все. Никаких дополнительных расходов!!!

Вот компоненты в Лазаре (на примере ZeosDB)


Вот свойства



Вот события


Что еще может быть быстрее и проще?
Ставишь в событии OnEventAlert на обновление графика в окне, прописываешь подписку на какое событий, активизируешь подписку - и все!
Да, это реально работает.

Цитата: Superwad от 02.02.2017 16:32:26Что еще может быть быстрее и проще?
Ставишь в событии OnEventAlert на обновление графика в окне, прописываешь подписку на какое событий, активизируешь подписку - и все!
Да, это реально работает.

В общем, да, мне на Оракле сейчас такой классной штуки не хватает.
На всякий случай скажу, что в ФБ, (думаю, и в других) эти события пересылаются клиенту по менее уровневому каналу, типа между сокетами tcp. Во времена IB они были глючными, приходилось для приёма событий делать отдельный коннект к БД чисто для приёма событий )

Цитата: Superwad от 02.02.2017 10:15:16"Элементарно. Ватсон" (с) Конан Дойль.
1) У Вас двухмерный массив Время:Данные. Записывать можно одномерный массив с данными, а ДатаВремя в отдельную колонку. Тут зависит только от ваше фантазии, что и как сделать.
2) Сбор данных, их периодичность и составление временного кадра с данными, опять же, описывается ТЗ и здравым смыслом. Можно тупо, периодичность опроса одних датчиков делать чаще, других реже (просто забивать в возвращаемом кадре предыдущие значения).
Это уже регламентируется логикой и физикой управляемого процесса (конечная цель ведь не сами данные, а управляемость заданного процесса в требуемых параметрах).
Так что все правильно говорите, но это совершенно не мешает составить правильно логику формирования временного кадра данных.

1) Например, вы собираете три величины A, B и C, каждая из которых представлена парой "время:значение". На некотором промежутке времени Вы имеете 305 пар величины A, 37 значений B и 193 значения C. Временная дельта у них гуляет процентов на 50%. Как я понимаю, у Вас будет три массива A[305], B[37], C[193]. И что Вы собираетесь с этими массивами делать?
2) Сбор данных в реальной системе достаточно случаен вне зависимости о того, что там написано в ТЗ. Когда оператор или алгоритм устанавливают шаг дискретизации, это не означает, что он будет именно такой. Обычно телеметрия идет с адаптивным дискретом -- если все стоит колом в пределах кванта значения, данные идут редко, как только зашевелилось, повалило все быстро. Например, телеметрия с котла, в котором горит мазут. Пока все в порядке, температура стенки идет с дискретом в секунды, как только датчики излучения от факела зафиксировали аномальные пульсации светимости, температура стенки начинает валить через десятую секунды и чаще. На всякий случай.
Помимо аналоговых есть и дискретные датчики - это те, которые выдают 1 или 0. Эти вообще ведут себя, как угодно. Бывает так, что в некотороый момент некоторая величина стала 1 (факт или сигнал открытия клапана). Начиная с этого момента с датчика состояния клапана идет последовательность единиц через равные промежутки времени (heart-beat), например, через секунду. Одновременно дискрет дюжины или более аналоговых датчиков, которое меряют, например, температуру, расход или давление сократился на порядок или более. Через какое-то время, например через 132 микросекунды после крайнего секундного тика, клапан закрылся. Состояние клапана  стало 0 и с этого момента его heart-beat сдвинулся на 132 мкс, но таки продолжает валить. Дискрет аналоговых датчиков увеличится не сразу, а через какое-то индивидуальное для каждого или группы время. И да, все этим заправляет прикладной уровень, который может быть реализован в непосредственной близи от датчиков на контроллерах, плисках, одноплатниках и даже в стойках, если группа зависимых датчиков большая, как например, на турбинах или самоварах. А может и удаленно в виде группы процессов на мощной многоядерной системе -- нынешнее серверное железо и коммуникационное оборудование позволяет адекватно рулить турбинами саяно-шушенской из спальни чубайса.

Цитата: slavae от 02.02.2017 18:23:48В общем, да, мне на Оракле сейчас такой классной штуки не хватает.
На всякий случай скажу, что в ФБ, (думаю, и в других) эти события пересылаются клиенту по менее уровневому каналу, типа между сокетами tcp. Во времена IB они были глючными, приходилось для приёма событий делать отдельный коннект к БД чисто для приёма событий )

В Оракле аналогичная фича именуется Oracle Advanced Queuing

Цитата: Поверонов от 02.02.2017 23:46:38В Оракле аналогичная фича именуется Oracle Advanced Queuing

Ничуть она не аналогична. Событие в ФБ проявляет себя как событие в компоненте в программе-клиенте. Они полностью асинхронны. Я не должен делать запрос, чтобы получить событие из очереди, эти события возникают в программе сами. 

Цитата: adolfus от 02.02.2017 22:59:091) Например, вы собираете три величины A, B и C, каждая из которых представлена парой "время:значение". На некотором промежутке времени Вы имеете 305 пар величины A, 37 значений B и 193 значения C. Временная дельта у них гуляет процентов на 50%. Как я понимаю, у Вас будет три массива A[305], B[37], C[193]. И что Вы собираетесь с этими массивами делать?
2) Сбор данных в реальной системе достаточно случаен вне зависимости о того, что там написано в ТЗ. Когда оператор или алгоритм устанавливают шаг дискретизации, это не означает, что он будет именно такой. Обычно телеметрия идет с адаптивным дискретом -- если все стоит колом в пределах кванта значения, данные идут редко, как только зашевелилось, повалило все быстро. Например, телеметрия с котла, в котором горит мазут. Пока все в порядке, температура стенки идет с дискретом в секунды, как только датчики излучения от факела зафиксировали аномальные пульсации светимости, температура стенки начинает валить через десятую секунды и чаще. На всякий случай.
Помимо аналоговых есть и дискретные датчики - это те, которые выдают 1 или 0. Эти вообще ведут себя, как угодно. Бывает так, что в некотороый момент некоторая величина стала 1 (факт или сигнал открытия клапана). Начиная с этого момента с датчика состояния клапана идет последовательность единиц через равные промежутки времени (heart-beat), например, через секунду. Одновременно дискрет дюжины или более аналоговых датчиков, которое меряют, например, температуру, расход или давление сократился на порядок или более. Через какое-то время, например через 132 микросекунды после крайнего секундного тика, клапан закрылся. Состояние клапана  стало 0 и с этого момента его heart-beat сдвинулся на 132 мкс, но таки продолжает валить. Дискрет аналоговых датчиков увеличится не сразу, а через какое-то индивидуальное для каждого или группы время. И да, все этим заправляет прикладной уровень, который может быть реализован в непосредственной близи от датчиков на контроллерах, плисках, одноплатниках и даже в стойках, если группа зависимых датчиков большая, как например, на турбинах или самоварах. А может и удаленно в виде группы процессов на мощной многоядерной системе -- нынешнее серверное железо и коммуникационное оборудование позволяет адекватно рулить турбинами саяно-шушенской из спальни чубайса.

Для того, чтобы грамотно разрулить такие ситуации, программист и тех.писатель задания должны быть специалистами в области, которую автоматизируют, т.е. химиками, атомщиками или теплотехниками. Только они могут правильно оценить правильность работы системы автоматического управления. Программист слишком узкоспециализирован - хорошо разбирается в электронике - и совсем (или почти совсем) не разбирается в процессах на автоматизируемом объекте. Потому и получаются те картинки, что бродят в интернете. что хотел заказчик, а что получил на выходе от программистов. Увы, это реальность. Как правильно все это связать - это нужен недюжий талант заказчика, который свяжет на себя и ТЗ написать и проконтролировать, что на выходе. Это единицы!!! В этом вся проблема на сегодня. Как бы ми не пыжились, лучше Заказчика, никто не знает всех нюансов техпроцесса. А полностью передать это, не получается.
ЗЫ. Я не спорю, что задачу можно решить по другому. Каждая проблема/задача может быть решена минимум двумя способами!!! Просто одни решения проще, другие - не очень.
PSS. Подписка на события почему-то реализованы только для версионников - видимо потому, что они более быстрые и у них минимальное время задержки от вставки до выдачи сигнала и считывания данных, это как раз для тех задач, когда скорость подачи информации укладывается в приемлемое время реагирования, которое обеспечивает та или иная БД.

Цитата: Поверонов от 02.02.2017 23:46:38В Оракле аналогичная фича именуется Oracle Advanced Queuing

Насколько я понимаю, из информации, полученной из мурзилок, при возникновении сбоя при вставке, изменении. удалении - скорость работы блокировочников - резко уменьшается до момента полного исправления ошибок. Это очень надежно, но - медленно . А для некоторых задач - нужно быстро, хоть и с приемлемой потерей данных. Задачи бывают разные и под разные задачи нужно использовать оптимальный инструмент, а не пихать универсальное решение. Его не существует!

Цитата: Superwad от 03.02.2017 07:14:53Насколько я понимаю, из информации, полученной из мурзилок, при возникновении сбоя при вставке, изменении. удалении - скорость работы блокировочников - резко уменьшается до момента полного исправления ошибок. Это очень надежно, но - медленно . А для некоторых задач - нужно быстро, хоть и с приемлемой потерей данных. Задачи бывают разные и под разные задачи нужно использовать оптимальный инструмент, а не пихать универсальное решение. Его не существует!

Если данные в ОЗУ меняются быстрее чем вы можете записать их на диск, то ничто не поможет - вы лишь можете отказаться от приема данных на время записи, либо использовать более быстрый хард - ssd или raid10 с большим массивом физических дисков. Другими словами зарегистрировать можно лишь те time-series которые укладываются в производительность внешнего регистратора. Это очевидно,  так что разговоры об универсальных БД - это только для заведомо очень медленных потоков.

Цитата: slavae от 03.02.2017 03:44:39Ничуть она не аналогична. Событие в ФБ проявляет себя как событие в компоненте в программе-клиенте. Они полностью асинхронны. Я не должен делать запрос, чтобы получить событие из очереди, эти события возникают в программе сами.

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

Цитата: Поверонов от 03.02.2017 08:32:17Если данные в ОЗУ меняются быстрее чем вы можете записать их на диск, то ничто не поможет - вы лишь можете отказаться от приема данных на время записи, либо использовать более быстрый хард - ssd или raid10 с большим массивом физических дисков. Другими словами зарегистрировать можно лишь те time-series которые укладываются в производительность внешнего регистратора. Это очевидно,  так что разговоры об универсальных БД - это только для заведомо очень медленных потоков.

Я с Вами полностью согласен!!! Именно эту мысль я и доносил своими сообщениями. Как упоминал ранее, все зависит от ТЗ и скорости реагирования на регулируемый процесс.
Любую задачу можно решить минимум двумя путями. Вопрос всегда упирается в оптимальность затрат - или железное, или в разработку или в др.
Что удобно и подходит для конкретной задачи - то и надо использовать, по возможности с минимумом затрат.

Цитата: Superwad от 03.02.2017 07:09:07Для того, чтобы грамотно разрулить такие ситуации, программист и тех.писатель задания должны быть специалистами в области, которую автоматизируют, т.е. химиками, атомщиками или теплотехниками. Только они могут правильно оценить правильность работы системы автоматического управления. Программист слишком узкоспециализирован - хорошо разбирается в электронике - и совсем (или почти совсем) не разбирается в процессах на автоматизируемом объекте.

С выделенным согласен в принципе. Разногласия лишь в отношении меры -- не нужно всем быть дипломированными теплотехниками, атомщиками и химиками, достаточно того, что дают в рамках общего курса в негуманиатарных вузах. Насколько я знаю, нет таких специальностей, где учат исключительно программированию. Любой программист - всегда по специальности инженер. А инженеру положено знать общий курс физики, химии, математики и радиоэлектроники. Если программист, то обязан знать еще и дискретную математику. Другой вопрос-- все ли владеют в полной мере тем, что у них написано во вкладыше к диплому. Кстати, самые лучшие прикладные программисты вырастают как раз из специалистов в тех или иных областях.

Цитата: adolfus от 03.02.2017 16:15:33Насколько я знаю, нет таких специальностей, где учат исключительно программированию. Любой программист - всегда по специальности инженер. А инженеру положено знать общий курс физики, химии, математики и радиоэлектроники

Увы - нет! К сожалению, сейчас данная проблема стоит "в полный рост" - программеры, "не нюхавшие" фактически ничего "физического". Железа, условно говоря. Отсюда -специфическое "мышление", авантюризм, безответственность. При этом, к сожалению, нередко помноженные на ничем не обоснованное напыщенное самомнение и презрение к людям, не являющимся программистами - заказчикам, пользователям. Тем самым "предметникам", кои могут ничего не понимать в особенностях динамической адресации или виртуальных методов, зато прекрасно разбирающимся в том, в чем программер ни смыслит ни шиша.

Цитата: TAU от 04.02.2017 00:38:50Увы - нет! К сожалению, сейчас данная проблема стоит "в полный рост" - программеры, "не нюхавшие" фактически ничего "физического".

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

Цитата: TAU от 04.02.2017 00:38:50... могут ничего не понимать в особенностях динамической адресации или виртуальных методов, зато прекрасно разбирающимся в том, в чем программер ни смыслит ни шиша.

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

Цитата: Yuri__1964 от 04.02.2017 23:07:40.. ну вот лично вы прошли курс общей химии, ну и много вы помните из этого, да и вообще сейчас наверно количество программистов больше чем всех инженеров вместе взятых.

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

Цитата: adolfus от 05.02.2017 01:21:03Вы действительно полагаете, что понимание особенностей динамической адресации (1) и виртуальных методов (2) необходимо для того, чтобы писать хорошие программы?
Кстатит, не уловил связи между (1) и (2)...

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

Цитата: Yuri__1964 от 04.02.2017 23:07:40Ну это не верно, программист совсем не обязательно инженер например выпускник математического факультета университета, ну какие у него знания по химии, а какие у инженера химика знания по электронике разве что уверенный пользователь телевизора, общие курсы на то и общие что чисто для расширения кругозора, ну вот лично вы прошли курс общей химии, ну и много вы помните из этого, да и вообще сейчас наверно количество программистов больше чем всех инженеров вместе взятых.

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

Цитата: Yuri__1964 от 06.02.2017 19:59:20Да будущий инженер-химик проходил семестровый курс электротехники на 2-м курсе и благополучно к 5-му всё забывал, это ведь нигде более не использовалось, без самостоятельного серьёзного изучения (на самом деле у инженера-химика просто недостаточная физико-математическая подготовка для таких дисциплин и не потому что тупые, а просто нельзя объять необъятное) можно смело считать уровень знаний по электротехнике-электроники выпускника химики-технологического факультета равными нулю

Не знаю как где, но у нас была очень сильная физико-математическя подготовка, дрючили по самое немогу. А электротехнику до сих пор помню, как и электронику, но я - это отдельная статья - я любил ковыряться и ремонтировать электронику, покупал соответствующие книги.