Scada Server. Текст (предложение)

[JurasskPark]

Добрый день!
Михаил, расскажите, что вы думаете о решение, когда в сервере появляется новое поле ValueId (integer), который будет ссылаться на отдельную таблицу-словарь.

TABLE ValueStrings (
ValueId INTEGER PRIMARY KEY,
Text TEXT NOT NULL UNIQUE
);

То есть в таблицу текуших значений при вставке текста, будет сохранятся только Id значения, а в словаре будет хранится сам текст и его ValueId. При вставке будет работать принцип Insert-Replace — если такая строка уже есть, но значение не вставляется, а возвращается уже существующий Id, а если нет, то возвращается вставляется новое значение.
Учитывая, что строки — это в 90% повторяющие одни и теже значения, то больших значений там не будет, а в текущих и исторических значениях будут хранится только id на текстовые значения.

[manjey73]

а смысл?
Самый простой путь.
N канала условно 1000, тип канала String, Тип данных UnicodeString

создай таблицу так же с id = 1000 и пихай туда всю строку, которую нужно.
В основной таблица будет храниться первые 4(8) символов строки, в дополнительной полные данные.

Один фиг обучать всех понимать новую БД, ее наличие и т.д. Коммуникатор, Таблицы, Мимик и так далее.

[JurasskPark]

А в исторических значениях нужно передавать значения по истории.
И вместо того, чтобы передавать по истории число
DateTime ValueId
2026-01-01 00:00:00 865
2026-01-01 00:01:00 865
2026-01-01 00:02:00 865
2026-01-01 00:03:00 865
2026-01-01 00:04:00 866 — Значение строкое изменилось и теперь Stop
2026-01-01 00:05:00 866

Ты предлагаешь хранить 1000 новых полей и хранить их историю изменений.
А тут в словаре есть
ValueId Text
865 Start
866 Stop

Андрей подключил насос и стал сохранять Stop, Start
Юра подключил пресс и стал сохранять Stop, Start.
И при вставке система поняла, что Андрей уже вставлял такие слова, значит она будет использовать уже готовые ValueId из словаря.

[manjey73]

Нет. Должен быть Гибрид БД.

Если у тебя в основной БД всего 50-т строковых каналов, то твоя БД состоят всего из 50-ти строк, просто их id совпадают с id основной БД.

Запись по изменению последних 20-ти — это одна БД. С меткой времени, с идентификаторами Оператора — короче КТО что-то поменял, включил, выключил. Комуникатор, Сервер, администратор Пупкин или Оператор Сидоров.

Иногда важно не просто два значения, а некоторое количество значений по времени, даже если они редко меняются.

[JurasskPark]

Речь про public struct CnlDataPoint.
Он представляет точку данных канала.

И если он будет иметь еще одно поле

        public CnlDataPoint(int cnlNum, DateTime timestamp, double val, int stat, int valueId)
        {
            CnlNum = cnlNum;
            Timestamp = timestamp;
            Val = val;
            Stat = stat;
            ValueId = valueId;
        }

то можно через него обращаться к таблицу-словарю строковых значений. Если значения строкового нет, то -1 или 0.

[manjey73]

хм, если сделать так

public CnlDataPoint(int cnlNum, DateTime timestamp, double val, int stat, int valueId = 0 )

то возможно даже никто не пострадает 🙂

[Mikhail]

Добрый день!
Сама по себе идея интересная.
Если говорить о её реализации в Rapid SCADA 6, то возникает проблема. ПО по умолчанию работает без использования БД, используя файловый архив, соответственно, в ней нет механизма хранения словарей строк. То есть нужно реализовывать дополнительный функционал в файловом архиве.

Ещё неочевидный момент: строка приходит от OPC-сервера и часто меняется. Такое бывает. В этом случае БД заполнится ненужными значениями. Для текущего среза этого не происходит, потому что данные записываются поверх. Таким образом, потребуется в БД разделять строки в текущих данных и в архиве. Желательно как-то контролировать, что строка больше не нужна и удалять её из БД.

[Mikhail]

Юра подключил пресс и стал сохранять Stop, Start.

Конкретно эта ситуация уже реализована через формат отображения перечислений. В архиве хранятся числа.

Указанный подход полезен, если оператор вводит произвольные строки, а не заранее известные из нескольких вариантов.

[JurasskPark]

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

Ещё раз. Речь про файловые архивы SCADA Server.

Появляется новый архив Текстовый архив.
В нём два поля ИД, Текст.

У архивов Текущий, Минутный, Часовой, Дневной — появляется новое поле ИД текстового архива.

С OPC сервера текстовые значения тоже для начала кто-то должен настроить на сохранение. Во-вторых, если их сейчас кто-то сохраняет, значит кому-то это нужно. В-третьих, если это строковое значение, не может же она быть счетчиком и иметь бесконечное количестсво вариантов.

[JurasskPark]

Ладно. Нет так нет. Построю своë казино с блекджеком и куртизанками. =]

[manjey73]

еще раз, аварии и события это другое.

а самое главное здесь, ну появится новое поле id текстовой БД, толку от этого поля, если с этим текстом никто не умеет работать? ни Таблицы, ни Mimic, ни Коммуникатор, ни даже Сервер.
Вот в чем вся зковыка.

А так, легко перенаправить любой id Базы в новую БД с тем же id + Текст.
По простому условию — Формат String И Тип данных UnicodeString (AsciiString)

И делай там базу уже какую хочешь и как хочешь.

[manjey73]

з.ы. вот банально ArcBasicText и присвой ей любой бит для подключения.

И эта DLL будет получать от кого-то строку и сохранять будет полностью.

Вопрос — а может ли он получить полную строку от Коммуникатора? — НЕТ
А от OPC сервера ? (тут не знаю)

[manjey73]

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

[JurasskPark]

Желательно как-то контролировать, что строка больше не нужна и удалять её из БД.

А если рядом с каждой папкой, где лежит .dat файл будет лежать файл .dict?
У нас же там лежит файл *_meta.dat, то почему ему можно, а dict нельзя?
То есть у каждой папки будет свой словарь, если если строк больше нет, то и словарь будет пустой?

[JurasskPark]

Главное свойство: ValueId имеет смысл только внутри одного дня.
Данные за понедельник лежат в папке Min/2025-06-29/.
Внутри этой папки есть свой словарь dict.dat.
ValueId = 5 в понедельничных файлах данных означает «пятая строка в понедельничном словаре».
Данные за вторник — в другой папке, со своим словарём. ValueId = 5 там будет означать совсем другую строку, и это нормально, потому что они никогда не пересекаются.

Внутри одного дня счётчик ссылок нужен только для одной цели — понять, можно ли удалить строку из словаря в течение дня. Но зачем её вообще удалять в течение дня? Словарь дня — это замкнутое множество строк, которые использовались в этот день. Оно формируется по мере поступления данных и живёт до конца дня.

Сценарий:
00:01 — пришла строка «RUN», добавили в словарь, ValueId = 1.
00:02 — та же строка, ValueId = 1, ссылок стало 2.
…
23:59 — ValueId = 1 использован последний раз.
00:00 — папка закрыта, словарь заморожен.

На следующий день создаётся новая папка с новым словарём. Строка «RUN» в нём появится снова и получит свой ValueId (например, тоже 1, если это первая строка дня). Данные за понедельник в это время спокойно лежат в понедельничной папке и ссылаются на понедельничный словарь.

Счётчик никогда не нужно обнулять — потому что он привязан не ко дню календаря, а к папке. Когда папка удаляется по retention (например, через 30 дней), вместе с ней удаляется и словарь, и все счётчики. Никакой синхронизации между днями не требуется.

Более того, счётчик ссылок внутри дня, скорее всего, вообще не нужен. Единственная причина его держать — это если нужно «схлопывать» словарь в реальном времени, удаляя строки, которые перестали использоваться (например, если тег был удалён или канал отключился). Но это редкий случай, и он не влияет на общую картину.

Строка «RUN» будет храниться один раз в каждом дневном словаре. За год — 365 копий. Это и есть «цена» решения.
Посчитаем:
«RUN» — 3 байта + 4 байта ValueId + заголовок ≈ 10 байт.
365 дней × 10 байт = 3.65 КБ в год на одну строку.
Без словаря, если тег пишется раз в секунду: 86400 × 3 байта × 365 = 94 МБ в год.
Разница в 25 000 раз. Дублирование между днями — это статистически ничтожная величина.

[Автор]

Записи