Timothy O'Rourke, vice president for computer and information services at Temple University in Philadelphia, said his staff can "start building reusable code with .Net to execute logic from SQL Server." That is "much more flexible and powerful" than putting business logic at the application server tier, he said.

But any IT shop that hopes to make heavy use of the new development options will need to do a careful analysis, because using .Net languages likely won't be the best approach for all of their database development work, according to several programming experts, analysts and users.

There will be plenty of instances where code written in T-SQL "will beat the pants off .Net CLR code," said Phil Hummel, a solution architect who works at Microsoft's technology center in Mountain View, Calif. "I don't want to see people waste time heading down the wrong track of trying to do everything with .Net procedures just because we have new features that will help people in some selected situations."

Users such as Keith Glennan, chief technology officer at Los Angeles-based Northrop Grumman Corp., are already anticipating the need for additional training to make sure their IT staffs can achieve optimal use of the CLR. Glennan said the new options will present a challenge to developers who are trying to determine when it's appropriate to embed code in a database.

On one hand, Glennan said, the new capabilities should make it simpler and more efficient for developers to encapsulate business rules within a database. But on the other hand, application logic embedded in the database will have to be controlled the same way that it was when it was in the application layer, he said. "The trade-off is between optimized performance and transparency of your object model," Glennan said. "It requires a lot of discipline in how and where you define objects and services. There's never a completely black and white answer to how you ought to do this."