Anthony Bloesch's Web Log

One of the features I would like to see in our tools for SQL Server is a T-SQL language service. This would give customers features like intellisense, text completion, refactoring (e.g. renaming a table everywhere at once), error highlighting (as in Word’s red squiggly underlining), and host of other features that C# and Visual Basic have in Visual Studio 2005. Unfortunately, implementing a language service for T-SQL requires solving some difficult problems....

The conventional way to persist the semantic data in a graphical database design/modeling tool is as a single binary file. This is easy to implement but does not mesh well with the text oriented tools developers typically use (e.g. editors, source code control systems, file diff and file searching utilities). In addition, if something goes wrong recovering your data is difficult. I think a better way to persist semantic information is as a small number of T-SQL creation scripts....

Thanks everyone for the great blog and email comments on how we should deal with T-SQL casing conventions. Here is a summary of that feedback....

I have been rethinking using uppercase letters for T-SQL keywords. Readability research shows that uppercase keywords are harder to read and experience shows they are harder to type. Is it just tradition that keeps T-SQL developers uppercasing keywords?...

SQL Server 2005’s support for XML has improved substantially. The new internal representation of XML and XML indexes supports much faster queries and updates. SQL Server 2005 supports querying and updating XML with XQuery, a powerful second-generation DML language for XML. Finally, SQL Server provides good support for converting between and relating relational and XML based data. Now that XML data has such good support in, the choice of when to use an XML column and when to use standard relation...

After you have been building databases for a while, surrogate keys become second nature but many people do not know about them so I thought I should devote some time to them. In addition, a constant challenge is choosing between using an int or a uniqueidentifier (i.e. GUID) as a surrogate key and I thought this would be a great forum to get some feedback on when you should use one or the other....

Compared with the development experience for, say, C# and Visual Basic the T-SQL development experience is terrible—no intellisense, refactoring, unit testing, code coverage or even good error reporting. Yet many developers spend large amounts of time building T-SQL code. SQL Server comes with a great set of tools for DBAs and for operational management but the T-SQL development experience is not even close to what I get with C#. ...