Yukon is still a ways off, but it's not too early to start preparing for the dramatic changes the new SQL Server release will bring—especially those associated with Microsoft's .NET Common Language Runtime (CLR). SQL Server 7.0 transformed SQL Server's underlying database-engine architecture, but the way that DBAs manage the server remained essentially the same. You still use Enterprise Manager for multiserver management and T-SQL to create and update databases and their objects. Although Yukon features the same underlying architecture, the release has big changes in store for DBAs.
With Yukon's CLR integration, you'll be able to use languages other than T-SQL to create database objects and retrieve and update data. T-SQL isn't going away, and some DBAs might try to simply ignore the new .NET languages they find in their toolbox. However, learning about the .NET Framework and the CLR will help you support the third-party applications that are certain to adopt these language enhancements and will help you understand where the enhancements can improve your own application and database performance.
You can start preparing for Yukon today by learning about the .NET Framework, its ADO.NET data-access object layer, and at least one of the .NET languages. The big language question is when should you use these new languages as opposed to T-SQL? To determine the best places to use a .NET language, you first need to investigate the characteristics of each alternative. For example, T-SQL is a powerful procedural language well suited to data retrieval and manipulation. However, T-SQL is weak in the areas of structure, flow control, and reusability, so applying T-SQL to problems that require complex logic is difficult. Object-oriented .NET languages such as Visual Basic .NET and C# provide adequate data-manipulation capabilities by using ADO.NET to execute SQL statements. But their strong points are structure and flow control, making them well suited for solutions that require complex logic. So, in general, T-SQL is better suited to raw data retrieval and modification, and the .NET languages are better suited to enforcing business rules.
The next step in preparing to take advantage of Yukon's language enhancements is to determine whether your existing stored procedures, triggers, and user-defined functions (UDFs) are primarily data-oriented or whether they implement business logic. If your procedures contain complex logic, you can begin expressing that logic in pseudo code, which will act as a guide to writing more-effective CLR stored procedures later. Or if you have Visual Studio .NET and are familiar with a .NET language, you could even begin rewriting the procedures in that language. You should also review your database design to see where your applications' data-access objects reside. With SQL Server's CLR integration, you'll be able to move your data-access objects from the data tier to the server, which could significantly boost your applications' performance.
You might not be able to roll out these procedures for a while. But time has a way of creeping up on you, and Yukon will be here before you know it. Nothing would put you in a better position to hit the ground running with the next release of SQL Server than to evaluate when and where to use the new CLR languages in your environment.