clr programming in sql server 2005

[nima_dir]

سلام دوستان
اگر براتون مقدوره میخواستم یکم اطلاعات درباره clr programming in .net بفرمایید.
چه نوع کدهای دات نت رو میشه تو استورها بنویسیم و آیا وقتی که استور رو ذخیره میکنیم بصورت clr ذخیره میشن
سپاسگزار

[hdv212]

شما در sql server قابلیت نوشتن تابع یا sp رو با کدهای دات پیدا میکنی، علاوه بر این شما میتونی از خیل عضیم کلاسهای مجود در دات نت، برای پردازش داده ها در sql server استفاده کنی که کارایی فوق العاده بالایی داره، مثلا میتونی از عبارات با قائده یا Regular Ecpression ها استفاده کنی، در سمت sql، پروسیجر هایی رو اجرا کنی که کارای غیر از خواندن اطلاعات از دیتابیس انجام بدن(مثلا اطلاعات از سیستم بگیرن)، این تازه قسمت کوچیکی از کارایی هست که میتونی با clr انجام بدی.

[nima_dir]

ممنون دوست عزیز
از لحاظ سرعت استوری که یه کاری رو همراه با کدهای دات نت انجام بده با استوری که همون کار رو با t-sql انجام بده چه تفاوتی هست؟
آیا استورهایی که درون انها از دات نت استفاده شده بصورت سی ال آر ذخیره میشن
ممنون

[AminSobati]

عملیات String Processing و Calculation در دات نت سریعتر از TSQL انجام میشه. اما برای دسترسی به اطلاعات و انجام عملیات Set Based (گزارش گیری) بهتره در TSQL کار رو انجام بدین

[nima_dir]

ممنون جنای ثباتی
و سوال دوم...

[مهدی کرامتی]

در طراحی اولیه قرار بود SQL Server قابلیت استفاده از کدهای CLR رو بصورت درون ساز (Built-In) داشته باشه، اما در عمل اینطور نشد و در نسخه نهایی 2005 برای اجرای کدهای CLR از COM Interop استفاده میشه که افت سرعت شدیدی رو در هر جایی که از کدهای فوق استفاده میشه بهمراه داره.

بنابراین اگر میشه کاری رو با T-SQL انجام داد، اصلا فکر نکنید که بهتره اون کار رو با CLR انجام بدید، و فقط زمانی به CLR برای انجام کارها فکر کنید که به هیچ وجه ممکن نباشه اون کار رو با T-SQL انجام بدهید.

توابع و پروسیجرهای CLR بعنوان بخشی از دیتابیس در اون ادغام (ذخیره) نمی شوند، بلکه بصورت یک فایل اسمبلی (DLL) میبایست در فایل سیستم در دسترس SQL Server قرار داشته باشند.

[hdv212]

با تشکر از DelphiAssistant عزیز
زمانی که شما در دیتابیستون، یه اسمبلی میسازید، این assembly در خود دیتابیس به صورت باینری ذخیره میشه، یعنی اگه شما دیتابیستون رو ببرید یه جای دیگه، این assembly هم باهاش میره و نیازی ندارید که dll ساخته شده رو باهاش اینور و اونور ببرید.

[AminSobati]

مشکل COM Interop در دسترسی و ساخت Objectها هست، نه در اجرای کد داخل اونها. با توجه به اینکه SQL Server بعنوان Dot NET Runtime Host طراحی شده، هم CLR و هم sqlservr.exe هر دو در یک Process هستند و تبادل اطلاعات و هر نوع Data Marshaling بسیار خوب بین اونها انجام میشه. همچنین وجود مکانیزمهای Garbage Collection و ... مزایایی هست که SQL Server از اون بهره میبره.
همونطور که اشاره کردم String Processing و بعضی محاسبات در CLR بهتر از TSQL انجام میشن.
در Books Online اشاره شده که:

managed code has a decisive performance advantage over Transact-SQL in terms of procedural code, computation, and string manipulation. CLR functions that are computing-intensive and that do not perform data access are better written in managed code. Transact-SQL functions do, however, perform data access more efficiently than CLR integration.

برای جزئیات دقیق تر:

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/denet9/html/7ce2dfc0-4b1f-4dcb-a979-2c4f95b4cb15.htm

زمانی که شما CREATE ASSEMBLY انجام میدین، بایت به بایت اون dll در دیتابیس شما ذخیره میشه و میتونین dll اصلی رو دور بندازین! این dll که اصطلاحا در دیتابیس شما Catalog (ذخیره) میشه همه جا همراه دیتابیس هست

[مهدی کرامتی]

تجربه ی CLR من در SQL Server 2005 مربوط به نسخه Beta 2 بود، اون موقع DLL میبایست در فایل سیستم نگهداری می شد، نمی دونم الان فرقی کرده یا نه.

با توجه به اینکه SQL Server بعنوان Dot NET Runtime Host طراحی شده، هم CLR و هم sqlservr.exe هر دو در یک Process هستند و تبادل اطلاعات و هر نوع Data Marshaling بسیار خوب بین اونها انجام میشه.

با عرض شرمندگی بابت این پرسش، اما آیا مرجعی وجود داره که من بتونم بیشتر در این باره بخونم؟

بر اساس تجربه ای که در فوق بهش اشاره کردم و تا جایی که از اون موقع ها یادم میاد در گفتگوی آنلاینی که با مسئول تیم توسعه SQL Server داشتم گفت قرار بوده نسخه SQL Server 2005 اون طوری باشه که شما فرمودید، اما به سبب کمبود وقت و کندی دات نت در نسخه نهایی از انجام اون کار (CLR Runtime Host بودن SQL Server) صرف نظر شد و از روش Interop برای استفاده از CLR در SQL Server بهره گرفته شد.

استفاده ای که من از CLR در SQL Server کردم این بود که یک Data Type جدید برای تاریخ شمسی با استفاده از CLR تعریف کردم، کار انجام شد، اما نتیجه کمی برایم عجیب بود. SQL Server برای نگهداری داده هایی که از نوع فوق تعریف شده بودند به ازای هر قلم داده یک Instance از کلاس من رو ایجاد میکرد، سپس اون رو Serialize کرده و در Page های فایل دیتابیس ذخیره میکرد. این کار باعث میشد دیتابیس بطور غیرمعقول بزرگ بشه. اگر جایی از این مطلب رو اشتباه گفتم لطفا تصحیح اش کنید.

[AminSobati]

کدهای CLR داخل SQL Server در محدوده ای به اسم Application Domain اجرا میشن و همونطور که اشاره شد در یک Process هستند. فلسفه وجود Application Domain، ایزوله کردن کدهای خود SQL Server از کدهای CLR ماست. یعنی حتی در صورت بروز جدی ترین باگ در کدهای CLR ما، SQL Server میتونه متد Dispose اون App Domain رو فراخوانی کنه و همه چیز تموم بشه، بدون اینکه در حافظه Crash رخ بده (این درست مشکلی بود که باگهای ما در Extended Procedureها در SQL Server ممکن بود ایجاد کنند و برای کدهای CLR به کلی مرتفع شد)
در خصوص جزئیات میزبانی Dot Net میتونین به Books Online مبحث CLR Hosted Environment رجوع کنید:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/denet9/html/d280d359-08f0-47b5-a07e-67dd2a58ad73.htm

در خصوص یکی بودن Processهای SQL Server و CLR، رجوع کنید به کتاب:
A Developer's Guide to SQL Server 2005 از انتشارات Addison Wesley فصل اول، مبحث The .NET Framework's Effects on SQL Server

در مورد UDTها، تمام انواع UDT باید توسط Storage Engine ابتدا Serialize بشن. اما در حالتی، میتونین اینترفیس های لازم رو خودتون Implement کنین و نحوه Serialize کردن رو به Storage Engine دیکته کنین. تعداد بایتهایی که توسط UDT اشغال میشه به پارامترهای زیادی بستگی داره. من از جزئیات کد شما اطلاعی ندارم.