LabVIEW Portal

В реализации проекта столкнулся с трудностями. Прошу помощи. Суть проблем такова. В БД MySQL необходимо сохранять данные в столбец типа DATETIME (c точностью до мс) и массив [240] double в столбец типа BLOB. Сначала пробовал с помощью ADOtoolkit (предложен на форуме). DATETIME с точностью до мс записывается в БД нормально, а считывается без мс. Пробежав форум разработчика данного тулкита понял, что чтение с мс не поддерживается. Поступил след образом: все таймстемпы конвертирую в формат LabView c началом отсчета 1янв1904г и получаю боольшооой такой DBL или INT, который с помощью ADOToolkit не читается. Почитав в который раз этот форум, нашел lv_mysql_connector_v1_lv8, работающий мимо ODBC-драйвера и его доработанную версию (Спасибо Borjomy_1!!!). Он с bigINT работает, НО...при считывании массива я получаю не один Variant с массивом, а несколько, причем разной длинны. Вручную клеить не хочется. Что посоветуете? Заранее спасибо

а хранить отдельно год, число, месяц, день, час, минуту, секунду, мсек слишком накладно выйдет?

Ради одного таймстемпа резервировать 8 столбцов... слишком жирно будет, что-ли. Да и разбирать из- собирать в- таймстемп накладно.

VladosXPOM писал(а):В БД MySQL необходимо сохранять данные в столбец типа DATETIME (c точностью до мс) и массив [240] double в столбец типа BLOB.

Вопрос в том, для чего в базу писать?
Что бы ее потом использовать в других средах или просто для хранения? Если необходимо только сохранить для дальнейшего использования в LabVIEW, то можно записать и в текстовом виде, как строку. Или как предложили - отдельно составляющие.

Если необходимо сделать именно экспорт, то нужно придерживаться стандарта MySQL и конвертировать именно в него по всем требованиям.

для чего в базу писать?

Писать с целью архивирования за длительный период (несколько мес) и обеспечить совместимость с любым ПО. Это раз. И хоть с MySQL я не профессионально знаком, но поиск ячейки с нужным DATETIME или bigINT в БД размером, скажем, 5-8 ГБ займет нААААмного меньше времени, чем поиск по восьми текстовым или числовым или любым другим полям. Это два. Поправьте если не прав

5-8 ГБ займет

может стоит разбивать на части? Я что-то заметил что никто и не смотрит на реализацию.... а смотрят на структуру хранения данных

Super Star писал(а):может стоит разбивать на части? Я что-то заметил что никто и не смотрит на реализацию.... а смотрят на структуру хранения данных

Конечно нужно разбивать, например 1 час - 1 файл.
Папка - день.

-------------

Тут нужно смотреть от количества данных.

Возможно и разбиваться будет а потом еще и архивироваться. И индексироваться. Это отдельная тема. Но что делать с размазанным массивом?

VladosXPOM писал(а):Возможно и разбиваться будет а потом еще и архивироваться. И индексироваться. Это отдельная тема. Но что делать с размазанным массивом?

На Ваш вопрос ответить не могу.

Хочу только высказать свои соображения...

Если Вы собрались писать в БД, то на мой взгляд писать каждый элемент в свой столбец.

Я бы пошел другим путем и придерживался следующей структуры. Создал бы структуру каталогов, например Данные писал в бинарные файлы (это наверное самый экономичный и быстрый формат записи без сжатия), отдельный файл для каждого часа, название соответствует времени начала записи.

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

Вообще-то я обходился и обхожусь форматом DBL для хранения таймстампа. Другое дело, что при просмотре базы этот таймстамп нечитаем стандартными средствами базы. Однако если чтение производится только программой под LV, то какие проблемы? Если хотите, чтобы их было видно и из базы, то пишите дататайм, а миллисекунды - отдельно, для этого достаточно и U16. У себя в проектах я просто дублировал таймстамп в DBL и в дататайме, чтобы стандартными средствами можно было увидеть время записи.

Что касается разбиения, то не имеет смысла делать таблицу на каждый час. Практика показывает, что даже в таблице размером 30Гб (полгода непрерывной работы, запись раз в секунду) поиск фрагмента по таймстампу в формате DBL занимает достойные 10-20сек. Основная причина разбиения на таблицы заключается в повышении надежности работы. Дело в том, что при нештатном завершении работы сервера (отрубание питания, на производстве) мы сталкивались с тем, что... повреждаются индексы и при следующем запуске программа перестает писать в базу. А восстанавливать многогигабайтную таблицу и долго и не факт, что успешно.

VladosXPOM, рабочий способ скидывал в личку

Рабочий способ от Borjomy_1 пришлось слегка подправить (выделил). Можно было бы поправить подприбор, но когда-нибудь потом. Теперь все работает. Спасибо