| I don't think avro helps in any way. Right now, the common solution is to have some query-builder library which is able to build up a SQL string for a given database based on higher level descriptions of what you want. See ActiveRecord, SQLAlchemy, etc. This lets the query-builder library hide differences between different sql languages as part of its internals. These query-builder libraries typically come as part of an ORM, which means you define your data as an object in your language (e.g. a ruby class). From what it looks like, avro would only be useful for replacing the definition of an object (the programming language class), but that's not a sticking point right now, and defining classes in your chosen language is easier than pulling in a different schema language... and replacing that portion still doesn't help with the true problem, which is that a SQL string for MySQL may not work on sqlite. I don't see how avro could help in regards to the different wire format different SQL databases have, nor could it help build queries as far as I can tell (e.g. knowing that 'ON DUPLICATE KEY ...' in mysql is kinda like 'ON CONFLICT ...' in sqlite).
Even if it could store these differences, the query-builder library already stores them quite efficiently in their language, and such libraries exist for almost every language. I do not see how Avro helps anything in this area. If you could describe in more specific detail where you think Avro might be relevant, I'd be happy to consider it from that angle. Your comment above is a bunch of words which talk about avro, but not about how it might apply to this specific problem. (Also, paragraph breaks help readability) |