- В этой теме 22 ответа, 3 участника, последнее обновление 3 часа, 48 минут назад сделано
.
-
Записи
-
Добрый день!
Михаил, расскажите, что вы думаете о решение, когда в сервере появляется новое поле ValueId (integer), который будет ссылаться на отдельную таблицу-словарь.TABLE ValueStrings (
ValueId INTEGER PRIMARY KEY,
Text TEXT NOT NULL UNIQUE
);То есть в таблицу текуших значений при вставке текста, будет сохранятся только Id значения, а в словаре будет хранится сам текст и его ValueId. При вставке будет работать принцип Insert-Replace — если такая строка уже есть, но значение не вставляется, а возвращается уже существующий Id, а если нет, то возвращается вставляется новое значение.
Учитывая, что строки — это в 90% повторяющие одни и теже значения, то больших значений там не будет, а в текущих и исторических значениях будут хранится только id на текстовые значения.а смысл?
Самый простой путь.
N канала условно 1000, тип канала String, Тип данных UnicodeStringсоздай таблицу так же с id = 1000 и пихай туда всю строку, которую нужно.
В основной таблица будет храниться первые 4(8) символов строки, в дополнительной полные данные.Один фиг обучать всех понимать новую БД, ее наличие и т.д. Коммуникатор, Таблицы, Мимик и так далее.
А в исторических значениях нужно передавать значения по истории.
И вместо того, чтобы передавать по истории число
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 из словаря.Нет. Должен быть Гибрид БД.
Если у тебя в основной БД всего 50-т строковых каналов, то твоя БД состоят всего из 50-ти строк, просто их id совпадают с id основной БД.
Запись по изменению последних 20-ти — это одна БД. С меткой времени, с идентификаторами Оператора — короче КТО что-то поменял, включил, выключил. Комуникатор, Сервер, администратор Пупкин или Оператор Сидоров.
Иногда важно не просто два значения, а некоторое количество значений по времени, даже если они редко меняются.
Речь про 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.
хм, если сделать так
public CnlDataPoint(int cnlNum, DateTime timestamp, double val, int stat, int valueId = 0 )то возможно даже никто не пострадает 🙂
Добрый день!
Сама по себе идея интересная.
Если говорить о её реализации в Rapid SCADA 6, то возникает проблема. ПО по умолчанию работает без использования БД, используя файловый архив, соответственно, в ней нет механизма хранения словарей строк. То есть нужно реализовывать дополнительный функционал в файловом архиве.Ещё неочевидный момент: строка приходит от OPC-сервера и часто меняется. Такое бывает. В этом случае БД заполнится ненужными значениями. Для текущего среза этого не происходит, потому что данные записываются поверх. Таким образом, потребуется в БД разделять строки в текущих данных и в архиве. Желательно как-то контролировать, что строка больше не нужна и удалять её из БД.
Юра подключил пресс и стал сохранять Stop, Start.
Конкретно эта ситуация уже реализована через формат отображения перечислений. В архиве хранятся числа.
Указанный подход полезен, если оператор вводит произвольные строки, а не заранее известные из нескольких вариантов.
Никто не говорит про базу данных, я говорю про файловый архив, и поэтому уточнил про CnlDataPoint, потому что Андрей со своими рассуждениям про авария и события собъет вас с мысли. Так и получилось.
Ещё раз. Речь про файловые архивы SCADA Server.
Появляется новый архив Текстовый архив.
В нём два поля ИД, Текст.У архивов Текущий, Минутный, Часовой, Дневной — появляется новое поле ИД текстового архива.
С OPC сервера текстовые значения тоже для начала кто-то должен настроить на сохранение. Во-вторых, если их сейчас кто-то сохраняет, значит кому-то это нужно. В-третьих, если это строковое значение, не может же она быть счетчиком и иметь бесконечное количестсво вариантов.
еще раз, аварии и события это другое.
а самое главное здесь, ну появится новое поле id текстовой БД, толку от этого поля, если с этим текстом никто не умеет работать? ни Таблицы, ни Mimic, ни Коммуникатор, ни даже Сервер.
Вот в чем вся зковыка.А так, легко перенаправить любой id Базы в новую БД с тем же id + Текст.
По простому условию — Формат String И Тип данных UnicodeString (AsciiString)И делай там базу уже какую хочешь и как хочешь.
з.ы. вот банально ArcBasicText и присвой ей любой бит для подключения.
И эта DLL будет получать от кого-то строку и сохранять будет полностью.
Вопрос — а может ли он получить полную строку от Коммуникатора? — НЕТ
А от OPC сервера ? (тут не знаю)опять же, строковая БД должна уметь работать по изменению, что для файлового варианта наверное тяжело реализуемо, хотя не знаю.
Желательно как-то контролировать, что строка больше не нужна и удалять её из БД.
А если рядом с каждой папкой, где лежит .dat файл будет лежать файл .dict?
У нас же там лежит файл *_meta.dat, то почему ему можно, а dict нельзя?
То есть у каждой папки будет свой словарь, если если строк больше нет, то и словарь будет пустой?Главное свойство: 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 раз. Дублирование между днями — это статистически ничтожная величина.
- Для ответа в этой теме необходимо авторизоваться.