сериализовать и десериализовать SQL-запрос

У меня есть встроенное устройство, в котором хранится список внутренних таблиц. Я хотел бы, чтобы он синхронизировал состояние этой таблицы с какой-либо внешней базой данных для целей отладки. То есть всякий раз, когда я добавляю элемент в определенный массив структур, я хочу, чтобы устройство выдавало команду «INSERT INTO ...».

Однако я отправляю данные по последовательному кабелю RS232, что делает недопустимыми накладные расходы на отправку явного SQL.

Поскольку я часто использую только 3 типа команд SQL, я могу сериализовать только эти несколько. А именно _1 _, _ 2_ и UPDATE.

Основная идея, которую я имел в виду, - отправлять данные с помощью «сжатого / сериализуемого» протокола SQL. Мы не будем отправлять команды напрямую на SQL-сервер, но на пользовательский сериализованный SQL-сервер я напишу:

  1. Мы присвоим номер каждому простому действию, изменяющему базу данных (например, INSERT, DELETE, UPDATE). Доступны только команды сериализуемого SQL: INSERT INTO x (), DELETE FROM x WHERE id=y. Где можно поменять только x и y.
  2. Сначала создайте все необходимые таблицы на сервере один раз. Храните на сервере хеш-таблицу, которая сопоставляет каждую таблицу с числом. Это можно сделать с помощью простого SQL, поскольку это делается только один раз.
  3. Затем присвойте номер каждой таблице, убедитесь, что сервер знает об этом номере.
  4. Наконец, всякий раз, когда мы хотим выполнить команду SQL, мы отправляем номер команды, за которым следует номер таблицы, за которым следует длина данных, за которыми следуют данные. Сервер определит структуру фактических данных по описанию таблицы.

Например

INSERT INTO temperature(temperature,location)
     VALUES ((108,"chille"),(120,"usa"))

Будет переведено на

[INSERT INTO id][2 data to send]
    [byte of 108][6 bytes string "chille"]
    [byte of 120][3 bytes "usa"]

и

DELETE FROM people (id,"bob") WHERE id=1 or id=2

Будет переведено на

[DELETE id][2 data to send][byte of 1][byte 2]

Поскольку id определяется как однобайтовое целое число.

Есть ли какой-нибудь известный протокол / реализация в этом духе?

Есть ли у кого-нибудь идеи получше?


sql binary protocols serialization embedded
person Elazar Leibovich    schedule 22.04.2009    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

Некоторые из ваших идей потребуют доработки - в частности, оператор ИЛИ в DELETE неочевиден. Кроме того, вам нужно будет определить, определяет ли ваше «N данных для отправки» количество строк или количество значений, а если количество строк, как вы определяете, сколько значений в строке.

person Jonathan Leffler    schedule 22.04.2009
comment
Спасибо за вклад! 1) Всегда количество строк, я всегда отправляю все значения для краткости протокола. 2) Я хочу обновлять / удалять ТОЛЬКО на основе уникального идентификатора, и если да, то имеет смысл только ИЛИ. Я предполагаю, что вы не знаете какой-либо подобной существующей реализации / протокола. Спасибо - person Elazar Leibovich; 22.04.2009

arrow_upward
0
arrow_downward

Возможно, вы делаете здесь преждевременную оптимизацию, особенно если учесть, что это только для тестирования. Я бы реализовал эту функцию, используя простой SQL, и посмотрел, как она работает.

Затем подумайте, сколько времени вам нужно, чтобы улучшить его, и сравните преимущества с другими вещами, которые вы могли бы сделать за это время. Например, добавить функцию, которую пользователь может купить.

person Andomar    schedule 22.04.2009
comment
Я на RS232, чувак. Я действительно не могу позволить себе даже отправить в 10 раз больше данных, чем имею сейчас. Не говоря уже об отправке в ASCII. Приличная среда отладки и прозрачное окно сократят примерно 75% времени отладки. Большая часть времени отладки тратится на добавление printf для просмотра такой информации. Надежная структура ведения журналов поможет гораздо больше, чем небольшая функция. - person Elazar Leibovich; 22.04.2009
comment
Не стоит недооценивать стоимость поддержки настраиваемой (вы сказали, надежной?) Структуры ведения журналов. Я видел, как люди тратят массу усилий на ведение журналов и уровни ORM, и очень удивлялись, когда их клиенты были недовольны. Но может я старею и сварю;) - person Andomar; 22.04.2009