Проблемы чтения-записи в MySQL

Работа с файлами и базами данных
Ответить
VladosXPOM
beginner
beginner
Сообщения: 40
Зарегистрирован: 21 мар 2014, 14:09
Версия LabVIEW: 2011
Контактная информация:

Проблемы чтения-записи в MySQL

Сообщение VladosXPOM »

В реализации проекта столкнулся с трудностями. Прошу помощи. Суть проблем такова. В БД 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 с массивом, а несколько, причем разной длинны. Вручную клеить не хочется. Что посоветуете? Заранее спасибо
Вложения
Содержимое MySQL DB
Содержимое MySQL DB
В третьем столбце должен быть считанный массив целиком, вместо этого он размазан
В третьем столбце должен быть считанный массив целиком, вместо этого он размазан
Последние два значения не на своих местах
Последние два значения не на своих местах
Это с помощью ADOToolkit: bigINT не прочитан (второй столбец), Массив из третьего столбца восстанавливается без проблем через Variant to string и string to array
Это с помощью ADOToolkit: bigINT не прочитан (второй столбец), Массив из третьего столбца восстанавливается без проблем через Variant to string и string to array
Аватара пользователя
Super Star
adviser
adviser
Сообщения: 228
Зарегистрирован: 07 фев 2013, 08:37
Версия LabVIEW: 2011

Re: Проблемы чтения-записи в MySQL

Сообщение Super Star »

а хранить отдельно год, число, месяц, день, час, минуту, секунду, мсек слишком накладно выйдет?
я люблю свою работу.... Я приду сюда в субботу ...
VladosXPOM
beginner
beginner
Сообщения: 40
Зарегистрирован: 21 мар 2014, 14:09
Версия LabVIEW: 2011
Контактная информация:

Re: Проблемы чтения-записи в MySQL

Сообщение VladosXPOM »

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

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5461
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Проблемы чтения-записи в MySQL

Сообщение IvanLis »

VladosXPOM писал(а):В БД MySQL необходимо сохранять данные в столбец типа DATETIME (c точностью до мс) и массив [240] double в столбец типа BLOB.
Вопрос в том, для чего в базу писать?
Что бы ее потом использовать в других средах или просто для хранения? Если необходимо только сохранить для дальнейшего использования в LabVIEW, то можно записать и в текстовом виде, как строку. Или как предложили - отдельно составляющие.

Если необходимо сделать именно экспорт, то нужно придерживаться стандарта MySQL и конвертировать именно в него по всем требованиям.
VladosXPOM
beginner
beginner
Сообщения: 40
Зарегистрирован: 21 мар 2014, 14:09
Версия LabVIEW: 2011
Контактная информация:

Re: Проблемы чтения-записи в MySQL

Сообщение VladosXPOM »

для чего в базу писать?
Писать с целью архивирования за длительный период (несколько мес) и обеспечить совместимость с любым ПО. Это раз. И хоть с MySQL я не профессионально знаком, но поиск ячейки с нужным DATETIME или bigINT в БД размером, скажем, 5-8 ГБ займет нААААмного меньше времени, чем поиск по восьми текстовым или числовым или любым другим полям. Это два. Поправьте если не прав
Аватара пользователя
Super Star
adviser
adviser
Сообщения: 228
Зарегистрирован: 07 фев 2013, 08:37
Версия LabVIEW: 2011

Re: Проблемы чтения-записи в MySQL

Сообщение Super Star »

5-8 ГБ займет
может стоит разбивать на части? Я что-то заметил что никто и не смотрит на реализацию.... а смотрят на структуру хранения данных
я люблю свою работу.... Я приду сюда в субботу ...
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5461
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Проблемы чтения-записи в MySQL

Сообщение IvanLis »

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

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

Тут нужно смотреть от количества данных.
VladosXPOM
beginner
beginner
Сообщения: 40
Зарегистрирован: 21 мар 2014, 14:09
Версия LabVIEW: 2011
Контактная информация:

Re: Проблемы чтения-записи в MySQL

Сообщение VladosXPOM »

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

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5461
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 27 раз
Поблагодарили: 86 раз

Re: Проблемы чтения-записи в MySQL

Сообщение IvanLis »

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

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

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

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

Код: Выделить всё

{год}  -  |
         {месяц}  -  |
                   {дата}
Данные писал в бинарные файлы (это наверное самый экономичный и быстрый формат записи без сжатия), отдельный файл для каждого часа, название соответствует времени начала записи.

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

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Проблемы чтения-записи в MySQL

Сообщение Borjomy_1 »

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

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

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Проблемы чтения-записи в MySQL

Сообщение Borjomy_1 »

VladosXPOM, рабочий способ скидывал в личку
VladosXPOM
beginner
beginner
Сообщения: 40
Зарегистрирован: 21 мар 2014, 14:09
Версия LabVIEW: 2011
Контактная информация:

Re: Проблемы чтения-записи в MySQL

Сообщение VladosXPOM »

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

Вернуться в «Сохранение данных»