serialize and deserialize SQL query

Question

I'm having an embedded device which keeps a list of inner tables. I would like it to synchronize this table's state with some outside database for debugging purposes. That is whenever I add an element to a certain struct array I wish the device to issue an "INSERT INTO ..." command.

However I'm sending the data over an RS232 serial cable, which makes the overhead of sending explicit SQL unacceptable.

Since there are only 3 types of SQL commands I use a lot, I can only serialize these few. Namely INSERT INTO,DELETE FROM, and UPDATE.

The general idea I had in mind is to send data with a "compressed/serializable" SQL protocol. We won't send commands directly to SQL server but to a custom serialized-SQL server I'll write:

1. We'll assign a number to each database-changing simple action (ie INSERT, DELETE, UPDATE). The only available serializable-SQL commands are INSERT INTO x (), DELETE FROM x WHERE id=y. Where we can only change x and y.
2. At first create all necessary tables on the server once. Keep a hash table on the server that maps each table to a number. This can be done in plain SQL as this is only done once.
3. Then assign a number to each table, make sure the server knows about this number
4. Finally whenever we wish to execute an SQL command, we'll send command number, followed by table number, followed by data length followed by data. The server would figure out the layout of the actual data by table's description.

For example

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

Would be translated to

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

and

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

Would be translated to

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

Since id is defined as a single byte integer.

Is there any known protocol/implementation in this spirit?

Does anyone have a better idea?

Answer 1

Most DBMS do this with prepared statements. You prepare a statement, such as an insert, and then execute it with just the relevant parameters. The server (or client) gives the prepared statement some sort of ID (typically, an integer, sometimes a string), and the client-side library can re-execute it on demand.

Some of your ideas will need refinement - the OR in the DELETE is not obvious, in particular. Also, you'd need to define whether your 'N data to send' identifies a number of rows or a number of values, and if a number of rows, how do you identify how many values in the row.

Answer 2

You might be doing premature optimization here, especially considering this is just for testing. I'd implement the feature using plain SQL and see how it performs.

Then consider the amount of time you'd need to improve it, and compare the benefits with the other things you could do in that time. Like add a feature a user might buy.