Проблемы с модулем экспорта в БД

[kustar]

Вот так это выглядит с конструкцией INSERT INTO; SELECT FROM WHERE;
Сделал временную табличку для одной строки, после копирования строки по условию в основную таблицу убиваю строку во временной таблице.

INSERT IGNORE INTO temp (datetime, cnlnum, val, stat)
VALUES (@dateTime, @cnlNum, @val, @stat);
INSERT IGNORE INTO cnldata (datetime, cnlnum, val, stat)
SELECT datetime, cnlnum, val, stat
FROM temp
WHERE cnlnum=’310′;
DELETE FROM temp;

Это работает, правда, коммуникатор быстрее накидывает данные, чем они обрабатываются этим скриптом. В результате — очередь переполняется минут за пять.
Можно, наверное, все делать в одной таблице — врЕменную строку записывать с каким-нибудь дополнительным уникальным номером и после обработки условия копировать запись без этого номера. Потом врЕменную строку стирать. Однако, не думаю, что будет быстрее.
Проблема в том, что невозможно анализировать данные от коммуникатора до их записи в таблицу. Или все же возможно?
Прошу помощи знатоков SQL.

[Romiros]

Как один из вариантов можно сделать две таблицы. Одна для текущих значений, другая для минутных. В первую просто Insert Ignore, как Вы и делали, но поставить триггер на удаление данных, которые старше минуты. На инсерт в эту таблицу повесить еще один триггер, который будет писать среднее значение в минутную таблицу. У меня MySQL под рукой нет, но там не сложно в инете полно примеров.

[kustar]

Да, спасибо. Так и пытаюсь делать!

[Mikhail]

Мой общий совет: используйте хранимые процедуры. Для отладки SQL-скриптов внутри этих процедур отложите Коммуникатор в сторону, а используйте стандартный MySQL Workbench.

[kustar]

Михаил, спасибо за совет. Сегодня было немножко времени — поковырял триггеры. Можно сделать, но некрасиво получается — запись строк с «правильными» номерами каналов сделать просто, а с «неправильными» — приходится писать в «мусорку», потом ее подтирать. Хранимые процедуры намного интереснее, больше возможностей.
Изучаю синтаксис и пунктуацию 🙂

[kustar]

STORED PROCEDURE работает отлично!
На MySQL выглядит вот так:

DELIMITER $$
CREATE DEFINER=root@localhost PROCEDURE ins_cnl(p1 DATETIME, p2 INT, p3 DOUBLE, p4 SMALLINT UNSIGNED)
COMMENT ‘Первая’
BEGIN
DECLARE cnl INT;
SET cnl = p2;
IF cnl = ‘304’ THEN
INSERT IGNORE INTO tempo (datetime, cnlnum, cif, stat) VALUES (p1, p2, p3, p4);
END IF;
END$$
DELIMITER ;

Столбец в таблице назвал cif, с именем val были какие-то непонятные проблемы.

И скрипт для модуля экспорта:
CALL ins_cnl(@dateTime, @cnlNum, @val, @stat);
Ну, для примера — только 304-й канал.

Михаил, как отправить запрос таблицам ScadaBase.sdf?
Если возможно, то предложение — в таблице InCnl сделать еще один столбец ForExport (Boolean)

[Romiros]

Сделайте в своей базе MySQL таблицу со списком каналов, которые необходимо экспортировать и используйте её в запросах.
А дополнительный столбец правда пригодился бы для собственных нужд. Только не Boolen, это сильно ограничивает возможности, какой-нибудь Varchar.

[kustar]

Сделайте в своей базе MySQL таблицу со списком каналов, которые необходимо экспортировать и используйте её в запросах.
Это несложно, но при организации новых каналов в Админе надо не забыть занести их (каналы) в еще одну таблицу другой базы. По мне, так надо все делать в одном месте.
Можно и VarChar. Автору виднее. В .sdf, кстати, подобные столбцы имеют тип BIT

[Mikhail]

Михаил, как отправить запрос таблицам ScadaBase.sdf?

Пока никак, к сожалению, т.к. это другая СУБД. Было несколько запросов на функции экспорта базы конфигурации в другие СУБД, но эти запросы не были подкреплены финансово.

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

В разных СУБД типы данных могут иметь разные имена, надо смотреть по смыслу в документации.

[Mikhail]

CALL ins_cnl(@dateTime, @cnlNum, @val, @stat);

Спасибо, это пригодится.

[Mikhail]

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

[kustar]

Пока никак, к сожалению
Да, мне тоже жаль. Придется воспользоваться советом Romiros #5716 🙂

Поэтому я предпочитаю PostgreSQL.
Этот пока еще free! На него тоже когда-нибудь найдется какой-нибудь Oracle!

А пока…
Server version: 5.7.16-log MySQL Community Server (GPL)
или
Server version: 10.0.26-MariaDB MariaDB Server — тоже GPL!
Признаться, пока даже не задумывался над этими проблемами.

Если делать Rapid на АРМе, то и .sdf достаточно. Если полноценный SCADA сервер — лучше бы эти ттаблицы вынести во внешнюю (общую с данными) СУБД.
Нет?

[Romiros]

Она итак вынесена. Папка BaseDat. База sdf только для конфигурации, а в работе участвуют файлы .dat

[Автор]

Сообщения