1) В пресс-релизах MS, посвященных Yukon очень часто можно встретить фразы "способость служить хостом CLR", "управляемый код выполняется в среде CLR, хостом для которой служит ядро баз данных" и т.п. Как на самом деле ядро взаимодействует с CLR? Можете привести хотя бы примеры простых функций подобного внутреннего взаимодействия или пояснить это на пальцах?
We are working very closely with CLR team to provide the best possible integration between SQL Server and CLR engine. Both components are tightly integrated. CLR leverages SQL Server memory management, thread scheduling, synchronization primitives and other OS services. SQL Server scheduling utilizes non preemptive scheduling without tight integration it will be possible for CLR engine to take over server’s schedulers and starve other requests. Moreover both engines, server and CLR, are very memory hungry. We had to come with ways for both of them to coexist in the same address space. So the integrations between CLR and Sever are much tighter and smoother as compare to COM for example. You can see the integration in action by executing select * from sys.dm_os_memory_clerks. There you might see clerks/caches for CLR, if you actually use them ?. In addition to CLR we also provided tighter integration with MDAC, SNAC. Now it leverages SQL Server OS services the same as CLR Engine.
2) Может ли разработчик под Yukon полностью отказаться от T-SQL в пользу управляемого кода? Означает ли такая мощная поддержка языков платформы в Yukon скорую гибель стандарта SQL в серверах БД MS?
I don’t think so. T-SQL and CLR will coexist happily for long time. However CLR will take over some things that are really painful to perform in T-SQL. Both of the technologies have their space under the sun, so I wouldn’t blindly jump on rewriting all T-SQL code in CLR

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение