I recently drafted a specification of a new database language - SQL# (pronounced "es-kju-el sharp"). It is available on http://sqlsharp.zlatko.michailov.org where I plan to publish future updates as well as samples and tools.
As far as the name is concerned - I really like it despite of the problems the # sign creates for file names and URLs. This name doesn't seem to be used yet - neither Google nor Bing find any literal matches. So until someone claims ownership of the name, SQL# it is.
Where did this come from? The programmability of Transact-SQL has been a pin in my eye for more than 10 years. My previous creature, Z-SQL, was a modest attempt to make T-SQL look and feel more like PL/SQL, but at the end of the day it was still SQL. I've grown to realize that the SQL legacy, in whatever flavor it comes, is what repells application developers. Even I started catching myself staring at seemingly valid SQL code that SQL Server was rejecting. When I realized I was writing in C# inside SQL Server Management Studio, I decided to take a more radical approach - to replace all the awkward SQL constructs with something that comes naturally - C#.
Of course, there are constructs like the data manipulation statements, SELECT/INSERT/UPDATE/DELETE, that only exist in SQL and cannot be replaced. We'll have to live with those for now, but for a large set of commonly used constructs like object definitions, variable declarations, loops, cursor traversals, etc. there is no reason why we should continue suffering. On top of this I add one of my favorite C/C++ features that is unfortunately missing in C# - preprocessor directives. While I only provision a limited preprocessor functionality, I believe I have captured the key use cases.
The most common question people have asked me is: Why SQL# when there is already LINQ? LINQ and SQL target two completely different classes of applications. I don't want to spark yet another discussion on which one is better. I would only say one doesn't exclude the other - LINQ did not (and will not) obsolete SQL especially in these times when the volumes of data organizations deal with grow faster than ever. Just like SQL made its way up to C# in the form of LINQ, I push C# down to SQL. I hope to find a similar reception from the SQL developer community.
What are the next steps? At this point I am seeking feedback on the overall usefulness of SQL# as well as on individual features - either proposed or missing. I am in no rush to start implementing any tooling that translates SQL# to Transact-SQL at least not until I am confident I've captured the right feature set. Even then, I will be looking for volunteers to write a compiler, a language service, and other tools. My goal is to continue driving the specification forward and to create an ecosystem of tool vendors.
So, if you are a SQL developer and you are interested in shifting your development experience in this direction, please read the spec and log your feedback here. It will be greatly appreciated.
