Ошибка — Дополнительные компоненты схем

[sakhalin_Cat]

Спасибо. Я уже почитал про этот пакет. Последняя версия была от 2007 года.
.
«В феврале 2013 года Microsoft объявила, что SQL Server Compact Edition устарела.

Хотя новых версий и обновлений не планируется, Microsoft будет продолжать поддерживать SQL Compact с помощью стандартной политики поддержки жизненного цикла. Эта поддержка завершится в июле 2021 года. »
.
Ну ничего другого не остается кроме как ждать новой версии с поддержкой внешних БД.

[manjey73]

Так тут речь о том, а нужны ли внешние БД ?

Точнее сказать так, нужно ли использовать запись всего и вся во внешние БД ?
Для настройки системы достаточно тех механизмов, что есть. Перенести только получаемые данные во внешние, но тогда все приложения должны уметь переключаться на работу с ними, чтобы отрисовывать графики и прочая, проводить какую-то аналитику например.
Я далек от понимания работы БД, но насколько вижу уже давно, она должна быть умной.
Если значение повторяется или долгое время одно и тоже, то ему как бы не место в постоянной записи. Изменилось, сохранили, поменял оператор — сохранили.
А тут получается все каналы сохраняются по умолчанию раз в минуту, даже если мы их никак не трогаем.

Но вроде в 6-й версии будут добавлены БД для различных вариантов, там и посмотрим.

[Romiros]

А тут получается все каналы сохраняются по умолчанию раз в минуту, даже если мы их никак не трогаем.

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

Уже сто раз обсуждали, просто ждем RapidScada-v6 🙂

[manjey73]

Romiros я немного о другом.

Например в течении часа у меня значение изменилось 5 раз. В текущем варианте это 60 записей в час независимо, менялось значение и сколько раз.

Правильный подход, 5 раз изменилось значение — 5 записей в БД — физических записей, то есть вместо 60-ти ячеек(объем ячейки не берем в расчет) памяти на диске, занято всего 5 ячеек.

Я не знаю, как правильно назвать такую базу. Но она будет меньше по размеру на диске, нежели текущая. Но вопрос как это сделать?
Понятно, что в 6-й версии появятся различные БД, но суть как сделать текущую таковой?
То есть я не должен настраивать как-то отдельно запись канала, стоит по умолчанию 1 минута и пусть, или я выставлю 30 сек. Но если за час было всего несколько изменений, то только они и записаны в память.

[Romiros]

Да обычные реляционные так и работают. Планируются Influx и Postgress. Если ничего не пишешь, то строчки и не добавляются. Видимо как-то так и будет в 6 версии. А сейчас scada работает с временными срезами каналов данных. Видимо скорость работы быстрее в таком виде. Да и мне в целом нравится, что я могу изменить данные в прошлом, а они ещё и пересчитаются по формулам. Для меня это решающий фактор.

[manjey73]

Самый простой способ, это если начальная ячейка таблицы была временной.
То есть минута настала — в эту минуту изменилось 1000 значений, значит на эту точку времени будет 1000 записей.
В следующий срез изменилось 587 значений, значит будет столько записей.
Соответственно одно поле это значения.
И такое же поле это статусы.

Но тут вопрос как искать по каналам тогда ? То есть надо будет искать канал с ближайшей точкой последней записи и предыдущей и строить график.

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

[Mikhail]

Упрощённо говоря, жёсткая структура архива выигрывает в производительности.
Т.к. тема совсем отклонилась о «Ошибка доп. компонентов схем», она закрывается.

[Автор]

Сообщения