LabVIEW Database Connectivity Toolset

Сразу предупреждаю – сейчас будет много критики. А критика это сложная штука. Потому что чувствуешь большую ответственность за сказанное, чем когда хвалишь что-то, и не хочешь оказаться в дураках, по причине недопонимания этого самого. Поэтому сразу сужу круг своей ответственности до LabVIEW Database Connectivity Toolset 1.0.1. Версия старая. В документации указан октябрь 2001.

Структура базы данных

Рассматривать будем простую таблицу, немного проще чем в моем дипломе.

CREATE TABLE IF NOT EXISTS `adcdata` (

`id`       INT(11)    NOT NULL AUTO_INCREMENT,
`channel`       INT(11)        NOT NULL,
`adcdata`       LONGBLOB       NULL DEFAULT NULL,
PRIMARY KEY (`Id`),
)Syhi-подсветка кода

LabVIEW Database Connectivity Toolset хорош

Начну, пожалуй, с хорошего. Это универсальная библиотека, работающая с любой базой данных, поддерживающей ODBC или OLE DB. Точно работает с Oracle, MS SQL Server, MySQL, Access.

Функции библиотеки (виртуальные приборы) очень похожи на функции классического ADO. Те же Connection-ы, те же RecordSet-ы. По RecordSet-у так же организуется проход курсором. Хочешь вызывай хранимые процедуры, хочешь делай параметризованные запросы, хочешь используй готовые функции (тогда и SQL писать не придется).

LabVIEW Database Connectivity Toolset плох

Основное предназначение LabVIEW – сбор и обработка данных. Данные – это чаще всего сигналы (аналоговые и цифровые). А сигнал это массив отсчетов (байт, слов). Логично подумать, что LabVIEW Database Connectivity Toolset должен уметь работать с двоичными данными. И он умеет! Но не совсем. В ходе своей работы я столкнулся с несколькими его ограничениями.

Во-первых, при записи сложных типов данных, например структур (кластеров) или массивов, Connectivity Toolset АВТОМАТИЧЕСКИ записывает перед данными их длину. 5 байт. Конечно, если считывать эти данные LabVIEW Database Connectivity, то все прекрасно, ибо он про эти 5 байт знает. А мне приходилось работать такими запросами:

INSERT INTO adcdata (channel, adcdata) 
VALUES (@channel, SUBSTRING(@adcdata FROM 5));Syhi-подсветка кода
Но эти самые 5 байт приходится обрубать и в запросах вида:

UPDATE adcdata
SET adcdata = CONCAT(adcdata, SUBSTRING(@adcdata FROM 5))
WHERE channel = @channel;Syhi-подсветка кода
Уж в этом случае добавление 5-ти байт в начало массива, точно является ошибкой разработчиков. К слову применение SUBSTRING к большим объемам данных пагубно сказывается на производительности.

Во-вторых, есть другая, еще более обидная проблем. Рассмотрим запрос:

SELECT adcdata FROM adcdata WHERE channel = @channelSyhi-подсветка кода

Напомню, что adcdata это двоичное поле типа LONGBLOB. А такой запрос, будучи выполнен средствами Database Connectivity Toolset, вернет только первые 65536 байт данных. Так уж устроен Database Connectivity Toolset. Самое интересное, то что никакими способами получить хотя бы один байт после первых 65536 у меня так и не получилось. Например, таким запросом:

SELECT BINARY SUBSTRING(adcdata, 65536, 2*65536)
FROM adcdata WHERE channel = @channelSyhi-подсветка кода
Двоичные данные при этом воспринимаются LabVIEW как символьная строка и кодируются странным образом. Никакие приведения данных средствами SQL не помогают.

А еще я так привык к ADO.NET, что мне очень не хватало класса типа DataAdapter и DataSet. Все-таки есть некоторая узкая специализация у LabVIEW и разрабатывать привычные нам приложения для работы с БД в нем трудновато. 

Например, стандартная задача: загрузка данных из БД в DataGrid, их правка и сохранение изменений обратно в БД. То что делается в Visual Studio за 15 минут в LabVIEW потребует значительных трудозатрат.

Резюме

1. Итак, у LabVIEW Database Connectivity Toolset оказалось два серьезных ограничения:
   Он без спроса записывает длину двоичных данных перед самими двоичными данными
2. Можно выбрать только первые 65536 точек. Но с оговоркой. Как я уже говорил, речь идет о версии 2001 года. В документации приводится информация об Oracle 7 и MS SQL 2000. И рассматриваются только типы данных VARBINARY и VARCHAR до 8000 байт. Никаких VARBINARY(MAX). Поэтому есть надежда, что второе ограничение устранено в новых версиях LabVIEW Database Connectivity Toolset.

А кроме того, учитывайте специфику LabVIEW как платформы для разработки приложений сбора и обработки данных. Некоторые вещи, в ней делаются довольно не просто. В качестве иллюстрации вот:

Это функция выборки всех записей из таблицы с 18-ю полями. И не так страшно создание этой функции, как скажем ее рефакторинг :)