Just recently a friend suggested it is possible and achievable (though very difficult) to write a SQL statement in assembly code, since every programming operation eventually gets down to processor-level execution.
I did a bit of research on SQL’s behaviour and although it follows relational algebra’s theory and platform-independent execution, I still believe that the level of abstraction and semantics are rather distant as to even consider a way to translate a SQL statement to assembly code (a very operations/memory/resources specific set of instructions).
Perhaps you could mimic a SQL statement’s processor operations result and try to replicate it with a pure assembly set of instructions. You would come to realise though, that you still would not be writing/translating SQL statements.
Take for instance, MonetDB’s SQL Reference page, they state the following in the third paragraph:
“The architecture is based on a compiler, which translates SQL
statements into the MonetDB Assembly Language (MAL). In this process
common optimization heuristics, specific to the relational algebra are
performed.”
The SQL language however does not even allow for brute assembly instructions to be typed, whereas common languages such as C-based, and C# do allow for such typing/imports.
What do you guys think? Thanks for sharing your thoughts!
Anything that runs on your computer can be coded using an assembly language. If a SQL database can run on your machine, then it can be coded in assembly.
It can be ridiculously hard to do though.
The SQL example you mention isn’t that far removed from what happens when C or other compiled languages are translated to machine code. Modern optimizing compilers don’t translate your C code directly to assembly. They use one (or more) intermediate representations that are easier to perform optimizations on. It’s a multi-step process, and the actual assembly output isn’t the main part of it complexity-wise.
If you look at it that way, your SQL case is not very different. You could imagine an SQL pre-processor that produces native code from the MAL given a sufficiently fixed environment (schema notably). With something like that, adding extensions to that SQL dialect to allow inline assembly (for aggregate functions for instance) could make sens. And doing all that manually (i.e. without the pre-processor itself) would be possible.
You loose all the portability and flexibility you get from a runtime SQL interpreter though, would have to recompile every time your schema changes, data-dependent optimizations become nearly impossible, etc. So the situations where this would be useful are, I believe, very limited. (Same thing for other languages that are usually run through a VM or interpreter – compiling them down to native code usually carries heavy restrictions.)