SQL is the assembly language of the modern world

The author's thesis: "I really would like to challenge the conventional wisdom that stored procedures are the best and/or that hand-crafted SQL is the only way to achieve good performance."<p>The author is obviously confused.<p>Both stored procedures (SPs) and dynamic SQL queries are "hand-crafted". Any craftsmanship difference between the two is the level of craftsmanship of the code author. In most shops SPs are written by more experienced SQL coders, usually a good thing.<p>In current databases (IIRC SQL Server also) execution plans are created at runtime for SPs as well as for dynamic SQL queries. So dynamic SQL has no guaranteed efficiency advantage arising from an updated execution plan.<p>Other advantages of restricting developers to use of SPs:<p>Security - SPs allow access control. By restricting developers to using SPs a DBA can restrict users and developers to particular operations/tables/fields.<p>Efficiency - SPs execute inside the database engine. Minimal network I/O (if any) is required. But a series of dynamic SQL operations may require moving the data outside the database proper, mandating record locking, network I/O, etc.<p>Maintainability - SPs allow data hiding. The DBA can restructure the database internally without requiring application rewrite.<p>Consequently any dynamic SQL operation can be rendered more efficient by rewriting it as a SP.

I don't think this article would ever have been written by someone with any significant amount of experience writing assembler.<p>The reasons to move away from low-level machine code and towards high-level languages like Java are numerous (safety, portability, programmer productivity), while the advantages of writing raw assembler basically boil down to two: low-level machine access and performance. The former is only useful to a small number of applications, and the latter is mostly covered by Moore's Law.<p>SQL, on the other hand, is not itself a low-level language. It has powerful, declarative constructs for efficiently dealing with large datasets, and modern database engines already serve as high-level runtime environments abstracting away the mundane details of page faults, index maintenance, and caching.

Considering the fact that SQL is a declarative query and data definition language, I don't know what kind of nasty, low-level stuff you would want to abstract away.<p>SQL may not be perfect, and there probably is a mismatch with the programming language, but is generating declarative statements from procedural/OO languages the best solution?

This sort of thing is often heard and there is a little truth to it, but people who think this way reveal more about themselves than the state of the art.<p>An assembly language is just a nice presentation for machine code which regulates the load, compute and store activity of some kind of processor and in a sense the familiar "crud" part of SQL expresses similar activity in some kind of database. Both are widely used and both are also fairly old and often automatically generated from higher level abstractions.<p>Whether or not either is modern is more of a function of what "level" you're operating. "Modern" has a different meaning to someone working at the level of Hadoop processes and Amazon services then to someone working with GPGPUs.

Surely, it is more like Cobol. Regardless, assembley and Cobol are quite primative.