استفاده یا عدم استفاده از یک تکنولوژی یا ابزار خاص، به پارامترهای مختلفی از جمله ابعاد پروژه، مهارت و دانش اعضای تیم، ماهیت پروژه، پلتفرم اجرا، بودجهی پروژه، مهلت تکمیل پروژه و تعداد نفرات تیم بستگی دارد. بنابراین واضح است پیچیدن یک نسخهی خاص، برای همهی سناریوها امکان پذیر نیست؛ اما شرایطی وجود دارد که استفاده یا عدم استفاده از این ابزارهای تکنولوژیک منطقیتر مینمایند.
Stored Procedure (که از این به بعد برای ایجاز، SP نوشته خواهد شد) هم از قاعده فوق مستثنی نیست و در صورت انتخاب صحیح میتواند به ارائهی محصول نهایی با کیفیتتری در زمان کوتاهتری کمک کند و در صورت انتخاب ناآگاهانه ممکن است باعث شکست یک پروژه (بخصوص در بلند مدت) شود.
تاریخچه
SQL توسط شرکت IBM در اوایل دهه 70 میلادی ایجاد شد. با اوج گرفتن زبانهای رویهای، SQL هم چندان از این قافله عقب نماند که منجر به پذیرش SP به عنوان یک استاندارد، در دهه 90 میلادی و پیاده سازی تدریجی آن توسط غولهای سازنده دیتابیس شد (رجوع فرمایید به ^ و ^). این فاصله 20 ساله باعث غنیتر شدن SQL شد و وجود SP - به معنی انتقال مدل برنامه نویسی رویهای به SQL - بخشی از مشکلات قبلی کار با کوئریهای پشت سر هم و خام را حل کرد. از سال 2000 میلادی به بعد، ORMهای قدرتمندی از جمله Hibernate و پیاده سازیهای مختلفی از Active Record و Entity Framework متولد شدند. بنابر این تقدم و تاخّرهای زمانی، بدیهی است اغلب مزایای SP نسبت به Raw SQL Query و اغلب معایب آن نسبت به ORMها باشد.
بنظر میرسد برای پاسخ به سوال اصلی این مطلب، ناگزیر به مقایسه SP با رقبای دیرینهاش هستیم. با برشمردن معایب و مزایای SP میتوان به نتیجهی منطقیتری رسید. البته باید در نظر داشت صرف استفاده از SP به معنای بهرهمند شدن از مزایای آن و صرف استفاده نکردن از آن هم بهرهمندی از رقبای آن نیست. چگونگی استفاده یک ابزار، مهمتر از خود ابزار است.
معایب SP
- دستورات Alter Table ، Add Column و Drop Column به این سادگیها هم نیستند؛ ممکن است به یکی از جداول دیتابیس دو ستون اضافه یا از آن حذف شوند. مجبوریم تمامی SPها را بخصوص Insert و Update متناظر با جدول را تغییر دهیم که این تغییرات ممکن است بصورت زنجیرهوار به سایر SPها هم سرایت کند. حال شرایطی را در نظر بگیرید که تعداد SPهای شما به چند ده و یا حتی به چند صد عدد و بیشتر، رسیده باشد که این به معنی زحمت بیشتر و تغییرات پر هزینهتر است.
- احتمال کند شدن ماشین سرویس دهنده در اثر اجرای تعداد
زیادی SP ؛ چناچه بخش زیادی از منطق برنامه از طریق SP اجرا شود، سرور دیتابیس موظف به اجرای آنهاست. اما در صورتیکه منطق،
در کد برنامه قرار داشته باشد، امکان توزیع آن بر روی سرورهای مجزا و یا حتی ماشین
کلاینت وجود خواهد داشت. امروزه اکثر کلاینتها به دیتابیسهای سبک و سریعی مجهز شدهاند. بنابراین در صورت امکان چرا بار پردازشی را به عهده آنها نگذاریم؟!
- یکپارچگی کمتر؛ تقریبا همه اپلیکیشنها نیازمند
ارتباط با سایر سیستمها هستند. اگر بخشهای زیادی از منطق برنامه درون SP مخفی شده باشند، این نقطه تلاقی بین سیستمی، احتمالا
درون خود دیتابیس قرار میگیرد و این به معنی ایجاد SP های بیشتر، افزودن
پارامترهای بیشتر، توسعه SPهای قبلی و بطور
خلاصه اعمال تغییرات بیشتر، که منتج به قابلیت نگهداری کمترخواهد شد.
- انعطاف پذیری کمتر؛ در یک شرایط ایده آل، عملکرد اپلیکیشن، مستقل از دیتابیس است. اگر نیاز به تغییر دیتابیس، مثلا از اوراکل به Microsoft SQL Server وجود داشته باشد، نیاز به بازنویسی و انتقال فانکشنها و SP ها محتمل است و از آنجائیکه که با وجود استانداردها، دیتابیسهای مختلف، معمولا در Syntax دستورات، تفاوتهای فاحشی دارند، هر چه کد بیشتری در SP ها باشد، نیاز به انتقال و تبدیل بیشتری وجود دارد.
- عدم وجود بازخورد مناسب؛ بسیاری از اوقات در صورت بروز اشکالی در حین اجرای یک SP، فقط با یک متن ساده بصورت Table has no rows و یا error مواجه میشویم. چنین خطاهایی هنگام دیباگ اصلا خوشایند نیستند. MS SQL در این بین بازخوردهای مناسبی را ارائه میکند. اگر تجربه کار با سایر دیتابیسها را داشته باشید، اهمیت بازخوردهای مناسب، ملموستر خواهد بود.
- کد نویسی سختتر؛ نوشتن کد SQL معمولا در همان IDE اپلیکیشن انجام نمیشود. جابجایی مداوم بین دو IDE ، دیباگ و کد نویسی از طریق دو اینترفیس مجزا، اصلا ایدهال نیست.
- SP منطق را بیش از حد پنهان میکند؛ حتی با دانستن نام صحیح یک SP، باز هم تصویری از پارامترهای ارسالی به آن و نتیجه برگشتی نخواهیم داشت. نمیدانیم نتیجه حاصل از اجرای SP ما مقداری را برمیگرداند یا خیر؟ در صورت وجود برگشتی، یک Cursor است یا یک مقدار؟ اگر Cursor است شامل چه ستونهایی است؟
- SP نمیتواند یک شیء را به عنوان آرگومان بپذیرد؛ بنابراین احتمال کثیف شدن کد به مرور افزایش پیدا میکند و بدتراز آن، در صورت ارسال اشتباه یک پارامتر، یا عدم تطابق تعداد پارامترها، مجبور به بررسی تمام آنها بصورت دستی هستیم. برای مثال دو قطعه کد زیر را با هم مقایسه کنید:
INSERT INTO User_Table(Id,Username,Password,FirstName,SureName,PhoneNumber,x,Email) VALUES (1,'VahidN','123456','Vahid','Nasiri','09120000000','vahid_xxx@example.com')
و معادل آن در یک ORM فرضی:
public void Insert(User user) { _users.Insert(user); db.Save(); }
بهوضوح قطعه کد sql، قبل از خوب یا بد بودن، زشت است. همچنین پارامتر x آن که فرضاً به تازگی اضافه شده، مقداری را دریافت نکرده و باعث بروز خطا خواهد شد.
- نبود Query Chaining؛ یکی از ویژگیهای جذاب ORMهای امروزی، امکان تشکیل یک کوئری با قابلیت خوانایی بالا و افزودن شرطهای بیشتر از طریق الگوی builder است. قطعه کد زیر یک SP برای جستجوی داینامیک نام و نام خانوادگی در یک جدول فرضی به اسم Users است:
public ICollection<User> GetUsers(string firstName,string lastName,Func<User, bool> orderBy) { var query = _users.where(u => u.LastName.StartsWith(lastName)); query = query.where(u => u.FirstName.StartsWith(firstName)); query = query.OrderBy(orderBy); return query.ToList(); }
در مقایسه با معادل SP آن:
CREATE PROCEDURE DynamicWhere @LastName varchar(50) = null, @FirstName varchar(50) = null, @Orderby varchar(50) = null AS BEGIN DECLARE @where nvarchar(max) SELECT @where = '1 = 1' IF @LastName IS NOT NULL SELECT @Where = @Where + " AND A.LastName LIKE @LastName + '%'" IF @FirstName IS NOT NULL SELECT @Where = @Where + " AND A.FirstName LIKE @FirstName + '%'" DECLARE @orderBySql nvarchar(max) SELECT @orderBySql = CASE WHEN @OrderBy = "LastName" THEN "A.LastName" ELSE @OrderBy = "FirstName" THEN "A.FirstName" END DECLARE @sql nvarchar(max) SELECT @sql = " SELECT A.Id , A.AccountNoId, A.LastName, A.FirstName, A.PostingDt, A.BillingAmount FROM Users WHERE " + @where + " ORDER BY " + @orderBySql exec sp_executesql @sql, N'@LastName varchar(50), @FirstName varchar(50) @LastName, @FirstName END
حاجت به گفتن نیست که قطعه کد اول چقدر خواناتر، انعطاف پذیرتر، خلاصهتر و قابل نگهداریتر است.
- نداشتن امکانات زبانهای مدرن؛ زبانها و IDEهای مدرن، امکانات قابل توجهی را برای نگهداری بهتر، انعطاف پذیری بیشتر، مقیاس پذیری بالاتر، تست پذیری دقیقتر و... ارائه میکنند. به عنوان مثال:
- شیءگرایی و امکانات آن که در SP موجود نیست و در مورد قبلی معایب، به آن مختصرا اشاره شد. در نظر بگیرید اگر SQL زبانی شیء گرا بود و مجهز به ارث بری و کپسوله سازی بود، چقدر قابلیت نگهداری آن بالاتر میرفت و حجم کدهای نوشته شده میتوانست کمتر باشند.
- نداشتن Lazy Loading که باعث مصرف زیاد حافظه میشود.
- نداشتن intellisense حین فراخوانیها.
- نداشتن Navigation Property که باعث join نویسیهای زیاد خواهد شد.
- SQL در مقایسه با یک زبان مدرن ناقص بنظر میرسد و این نوشتن کد آن را سختتر میکند.
- نداشتن امکان تغییر منطقی نام جداول و ستون ها
- مدیریت تراکنشها بصورت دستی، حال آنکه با الگوی Unit Of Work این مشکل در یک ORM قدرتمند مثل EF حل شده است.
- زمان بر بودن نوشتن SP؛ گاهی نوشتن یک تابع در یک ORM یا بعضا نوشتن یک کوئری SQL کوتاه در یک رشته متنی، سادهتر از نوشتن کد SP است. آیا برای هر وظیفه کوچک در دیتابیس، نوشتن یک SP ضروری است؟
مزایای SP :
- کمتر کردن Round Trips در شبکه و متعاقبا کاهش ترافیک شبکه؛ اگر از یک فراخوانی استفاده کنیم، کاهش Round Tripها تاثیر چندانی نخواهد داشت. همچنین ارسال یک کوئری کامل، نسبت به ارسال فقط اسم SP و پارامترهای آن، پهنای باند بیشتری اِشغال میکند. البته در یک شبکه با سرعت قابل قبول، بعید است این دو مزیت محسوس باشند؛ اما به هر حال برای موارد خاص، دو مزیت محسوب میشوند. نکته دیگر آنکه بدلیل Pre-Compiled بودن SPها و همچنین کَش شدن Execution Plan آنها، اندکی با سرعت بالاتری اجرا میشوند.
- امکان چک کردن سینتکس قبل از اجرای آن؛ در مقایسه با Raw Query مزیت محسوب میشود.
- امکان به اشتراک گذاری کد؛ برای پروژههایی که چندین اپلیکیشن با چندین زبان برنامه نویسی مختلف در حال تهیه هستند و نیازمند دسترسی مستقیم به دادهها با سرعت به نسبت بالاتری هستند، SP میتواند یک راه حل ایده آل محسوب شود. بجای پیاده سازی منطق برنامه در هر اپلیکیشن بصورت جداگانه و زحمت کدنویسی هرکدام، میتوان از SP استفاده کرد. هرچند امروزه معمولا برای حل این مشکل، API های مشترک معماری Restful ارجحیت دارد.
- کمک به ایجاد یک پَک؛ در یک زیر سیستم با نیازمندی مشخص که اعمال تغییرات در آن محتمل نمیباشد نیز SP میتواند یک گزینه مناسب به حساب آید. مثلا یک سیستم Membership را در نظر بگیرید که در پروژههای مختلف شما مورد استفاده قرار خواهد گرفت. برای مثال میشود یک سیستم Membership سفارشی را با امکان Hash پسورد و رمز کردن دادههای حساس، به کمک SP و Function های مناسب فراهم کرد و در واقع بین Application Login و Data Logic تمایز قائل شد. شخصا معماری Restful را به این روش هم ترجیح میدهم.
- بهرمند شدن از امکانات بومی SQL ؛ به عنوان نمونه برای ترانهاده کردن خروجی یک کوئری میتوان از فانکشن Pivot استفاده کرد. یا فانکشنهای تحلیلی Lead و Lag (لینک مستندات اوراکل این دو فانکشن به ترتیب در ^ و ^ ) که بنظر نمیرسد هنوز معادل مستقیمی درORM ها داشته باشند.
- تسلط و کنترل بیشتر و دقیقتر بر کوئری نهایی؛ گفته میشود SP و عبارات SQL در دیتابیس، حکم assembly را در سایر زبانها دارند. بنابراین با SP میتوان عبارات SQL و نحوه اجرای آن را در دیتابیس، بطور کامل تحت فرمان داشت. این در حالی است که هر یک از ORMها دستورات زبان برنامه نویسی مبداء را به یک عبارت SQL ترجمه میکنند که این عبارت چندان تحت کنترل برنامه نویس نیست و بیشتر به مدل کاری ORM بستگی دارد.
- امکان join بین دو یا چند دیتابیس مجزا؛ حال آنکه امکان join بین دو Context در ORM ها وجود ندارد. بعلاوه اگر دو دیتابیس مدنظر ما روی دو سرور مجزا باشند، با SP و کانفیگ Linked Server کماکان میشود کوئری join دار نوشت.
- برای عملیاتهای Batch مناسبتر است؛ در مقام مقایسه با ORM ها که با تکنیکهای مختلفی سعی در افزایش سرعت عملیات Batch، بخصوص Insert و Update را دارند، SP با سرعت قابل قبولتری اجرا میشود.
- عدم نیاز به یادگیری سینتکس و ابزاری جدید؛ موارد
بسیاری وجود دارند که فرصت یادگیری تکنولوژی جدیدی مثل یک ORM و یا SQL Bulk و حتی کتابخانههای ثالث مبتنی بر این ابزارها وجود ندارند و ممکن است مجبور شوید برای باقی ماندن در بازار رقابتی، از
دانستههای قبلی خود استفاده کنید .
- تخصصیتر کردن وظایف؛ برنامه نویسهای دیتابیس به صورت تخصصی اقدام به تحلیل روابط و ایندکسها میکنند، دیتابیس را ایجاد و نرمال سازی مینمایند، SP های متناسب را میسازند و به بهترین شکل Optimize و در آخر تست میکنند.
- امنیت به نسبت بالاتر؛ میتوان مجوز اجرای SP را به یک کاربر اعطا کرد، بدون آنکه مجوز دسترسی به جداول مورد استفاده در آن SP را داد. همچنین نسبت به کوئریهای پارامتری نشده، SQL ارجیحت دارند چون احتمال آسیب پذیری در مقابل SQL Injection را کمتر میکنند.
نتیجهگیری
اگرچه SP ها برای پردازش دادهها آنقدر هم که در وبلاگها میخوانیم بد نیستند، اما سوء استفاده از آن، مشکلات عدیدهای را ایجاد خواهد کرد. با توجه به روند تغییرات تکنولوژیهای دسترسی به دادهها و معماریهای مدرن بنظر میرسد SP در بهترین حالت، ابزار مناسبی برای انجام عملیات CRUD است و نه بیشتر؛ مگر در مواردی خاص که به تشخیص شما نیاز به استفاده بیشتر از آن وجود داشته باشد.
متن زیر یک سری نکات و یا شاید توهماتی را مطرح میکند که در مورد رویههای ذخیره شده در اس کیوال سرور رایج هستند.
1- رویههای ذخیره شده در مقابل SQL Injection مقاوم هستند. کوئریهای Ad hoc همیشه این آسیب پذیری را به همراه دارند.
نادرست است! رویههای ذخیره شدهای که رشتهها را به صورت پارامتر دریافت کرده و آنها را به صورت یک عبارت sql اجرا میکنند، آسیب پذیر هستند. اگر هنگام استفاده از کوئریهای Ad hoc از پارامترها استفاده شود، در برابر حملات SQL Injection مصون خواهید بود.
2- execution plan رویههای ذخیره شده کش میشوند اما این Plan برای کوئریهای Ad hoc هر بار محاسبه و تولید میگردد.
نادرست است! اس کیوال سرور تا این اندازه بی هوش نیست! اگر execution plan ایی موجود باشد حتما استفاده خواهد شد و برای موتور اس کیوال سرور اصلا اهمیتی ندارد که کوئری در حال اجرا از یک رویه ذخیره شده صادر شده است یا از یک کوئری Ad hoc . رویههای ذخیره شده پیش کامپایل شده نیستند و مانند تمامی کوئریهای دیگر در زمان اجرا کامپایل میشوند.
3- زمانیکه از رویه ذخیره شده استفاده میکنید همه چیز را در یک مکان به صورت متمرکز و مجتمع خواهید داشت (مدیریت بهتر)
نادرست است! در یک مکان متمرکز در اختیار شما نیستند. برنامه جای خود را دارد و رویههای ذخیره شده در دیتابیس در جای دیگری قرار دارند و برای مثال اگر قرار باشد یک پارامتر را به رویه ذخیره شده خود اضافه کنید، کدهای شما نیز باید تغییر کنند.
4- میتوان از یک رویه ذخیره شده استفاده مجدد کرد (در نقاط مختلف یک کد) و اعمال تغییرات تنها در یک مکان (دیتابیس) باید صورت گیرد.
هر چند این مورد درست است، اما باید دقت داشت که اگر چندین برنامه از این رویه ذخیره شده استفاده میکنند نباید تغییرات شما باعث از کار افتادن سایر برنامهها شوند.
5- میتوان رویه ذخیره شده را بدون نیاز به توزیع مجدد برنامه تغییر داد.
این مورد تا حدودی صحیح است. اگر تنها بحث بهینه سازی و امثال آن مطرح باشد صحیح است اما اگر واقعا نیاز به تغییر یک کوئری در رویه ذخیره شده وجود داشته باشد به احتمال زیاد برنامه نیز باید دستخوش تغییراتی گردد تا این دو با هم هماهنگ شوند.
نظر شما چیست؟
بررسی عملگر hash join
ابتدا در management studio از منوی Query، گزینهی Include actual execution plan را انتخاب میکنیم. سپس کوئریهای زیر را اجرا میکنیم:
USE [WideWorldImporters]; GO SET STATISTICS IO ON; GO /* Query with a hash join */ SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Warehouse].[StockItems] [si] JOIN [Sales].[OrderLines] [ol] ON [si].[StockItemID] = [ol].[StockItemID]; GO
دیتاست بالایی که ضخامت پیکان خارج شدهی از آن کمتر است، تعداد ردیفهای کمتری را نسبت به دیتاست درونی دارد (227 ردیف، در مقابل بیش از 231 هزار ردیف).
با حرکت اشارهگر ماوس بر روی هر کدام از ایندکسها، میتوان با دقت کردن به Output List آنها، دقیقا دریافت که هرکدام، چه ستونهایی از کوئری نهایی را تامین میکنند:
دیتاست بالایی که از PK_Warehouse_StockItems تامین میشود:
ALTER TABLE [Warehouse].[StockItems] ADD CONSTRAINT [PK_Warehouse_StockItems] PRIMARY KEY CLUSTERED ( [StockItemID] ASC )
دیتاست درونی که از NCCX_Sales_OrderLines تامین میشود و یک COLUMNSTORE INDEX است:
CREATE NONCLUSTERED COLUMNSTORE INDEX [NCCX_Sales_OrderLines] ON [Sales].[OrderLines] ( [OrderID], [StockItemID], [Description], [Quantity], [UnitPrice], [PickedQuantity] )
بهبود کارآیی hash join با فشرده سازی ایندکسهای آن
ایندکس NCCX_Sales_OrderLines که در کوئری فوق مورد استفاده قرار گرفته، همانطور که در قسمتی از تعریف آن نیز مشخص است، تعداد ستونهای بیشتری را از آنچه ما نیاز داریم، در بر دارد. در این حالت آیا اگر ایندکس مناسبتری را با تعداد ستون کمتری ایجاد کنیم، از آن استفاده میکند؟
CREATE NONCLUSTERED INDEX [IX_OrderLines_StockItemID] ON [Sales].[OrderLines]( [StockItemID] ASC, [PickedQuantity] ASC, [OrderID]) ON [PRIMARY]; GO
در این حالت اگر کوئری زیر را اجرا کنیم:
SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Sales].[OrderLines] [ol] JOIN [Warehouse].[StockItems] [si] ON [ol].[StockItemID] = [si].[StockItemID] OPTION (RECOMPILE); GO
یک نکته: در این کوئری علت استفادهی از RECOMPILE، وادار کردن SQL server به محاسبهی مجدد کوئری پلن جاری است.
اکنون اگر نگارش فشرده شدهی ایندکسی را که ایجاد کردیم، با ذکر گزینهی DATA_COMPRESSION = PAGE تعریف کنیم، چه اتفاقی رخ میدهد؟
CREATE NONCLUSTERED INDEX [IX_OrderLines_StockItemID_Compressed] ON [Sales].[OrderLines]( [StockItemID] ASC, [PickedQuantity] ASC, [OrderID]) WITH (DATA_COMPRESSION = PAGE) ON [PRIMARY]; GO
یک نکته: اگر علاقمند بودید تا هزینهی این کوئریها را نسبت به یکدیگر محاسبه و مقایسه کنید، چون یک کوئری معمولی، همواره از آخرین پلن محاسبه شده استفاده میکند، اینکار میسر نیست. اما میتوان با ذکر صریح ایندکس مدنظر توسط راهنمای WITH INDEX، بهینه ساز کوئریها را وارد کرد تا از ایندکسی که ذکر میشود، بجای ایندکسی که فکر میکند بهتر است، استفاده کند. بنابراین اجرای هر 4 کوئری زیر با هم، 4 کوئری پلن متفاوت را بر اساس ایندکسهای متفاوتی، محاسبه کرده و نمایش میدهد:
SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Sales].[OrderLines] [ol] JOIN [Warehouse].[StockItems] [si] ON [ol].[StockItemID] = [si].[StockItemID] OPTION (RECOMPILE); GO SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Sales].[OrderLines] [ol] WITH (INDEX (IX_Sales_OrderLines_Perf_20160301_02)) JOIN [Warehouse].[StockItems] [si] ON [ol].[StockItemID] = [si].[StockItemID]; GO SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Sales].[OrderLines] [ol] WITH (INDEX (IX_OrderLines_StockItemID)) JOIN [Warehouse].[StockItems] [si] ON [ol].[StockItemID] = [si].[StockItemID]; GO SELECT [ol].[OrderID], [ol].[OrderLineID], [ol].[StockItemID], [ol].[PickedQuantity], [si].[StockItemName], [si].[UnitPrice] FROM [Sales].[OrderLines] [ol] WITH (INDEX (IX_OrderLines_StockItemID_Compressed)) JOIN [Warehouse].[StockItems] [si] ON [ol].[StockItemID] = [si].[StockItemID]; GO
بررسی عملگر compute scalar
کار عملگر compute scalar، ارزیابی و محاسبهی یک عبارت است و خروجی آن نیز یک مقدار scalar است؛ مانند functions در SQL Server. مشکلی که با این عملگر وجود دارد این است که هزینهی انجام آن عموما در کوئری پلن ظاهر نمیشود (و یا با تخمین نادرستی ظاهر میشود) که میتواند گمراه کننده باشد. همچنین پلن حاصل، اشیایی را که توسط یک function مورد استفاده قرار میگیرند، لحاظ نمیکند.
برای نمونه اگر پلن دو کوئری زیر را با هم مقایسه کنیم:
SELECT COUNT(*) FROM [Sales].[Orders]; SELECT COUNT_BIG (*) FROM [Sales].[Orders];
از این جهت که (*)COUNT در SQL server به (*)COUNT_BIG تفسیر شده و اجرا میشود. به همین جهت آنچنان تفاوتی در اینجا قابل مشاهده نیست.
اما اگر function زیر را تعریف کنیم:
CREATE FUNCTION dbo.CountProductsSold ( @SalesPersonID INT ) RETURNS INT AS BEGIN DECLARE @SoldCount INT; SELECT @SoldCount = COUNT(DISTINCT [ol].[StockItemID]) FROM [Sales].[Orders] [o] JOIN [Sales].[OrderLines] [ol] ON [o].[OrderID] = [ol].[OrderID] WHERE [o].[SalespersonPersonID] = @SalesPersonID RETURN (@SoldCount); END
SELECT [FullName] AS [SalesPerson], [dbo].[CountProductsSold]([PersonID]) AS [NumberOfProductsSold] FROM [Application].[People] WHERE [IsSalesperson] = 1;
یک روش محاسبهی هزینهی فراخوانی این تابع، استفاده از extended events است. روش دیگر آن استفاده از اشیاء DMO's میباشد:
SELECT [fs].[last_execution_time], [fs].[execution_count], [fs].[total_logical_reads]/[fs].[execution_count] [AvgLogicalReads], [fs].[max_logical_reads], [t].[text], [p].[query_plan] FROM sys.dm_exec_function_stats [fs] CROSS APPLY sys.dm_exec_sql_text([fs].sql_handle) [t] CROSS APPLY sys.dm_exec_query_plan([fs].[plan_handle]) [p];
بنابراین compute scalar صورت گرفته دارای هزینهای است که در actual execution plan ظاهر نمیشود.
اکنون اگر از منوی Query، گزینهی Include actual execution plan را انتخاب نکنیم و بجای آن گزینهی Display estimated execution plan را انتخاب کنیم، به تصویر زیر خواهیم رسید:
در نیمهی پایینی آن، جزئیات دسترسیهای تابع فراخوانی شده نیز ذکر میشوند. بنابراین استفادهی از estimated execution planها در حین کار با توابع، بسیار مفید است.
3.Visual Studio 2019 RC منتشر شد
- Modal progress dialog stays open permanently even when IDE is responsive ('Preparing Solution', 'Creating Project', Edit and Continue, etc).
- PackageId:OpenJDKV1;PackageAction:Uninstall;ReturnCode:0;.
- .sql files are empty.
- Properties Window in Forms Designer shows vertical scrollbar without drag handle with automatic scaling on 4K display in Visual Studio 2019 RC.
- VSIXInstaller.exe crashes randomly when installing multiple extensions sequentially in Visual Studio 2019 RC.1.
- MSBuild failure when executing multi-line Exec commands.
- You can now use Time Travel Debugging with the snapshot debugger on ASP.NET Apps running on an Azure VM. Please note that this feature may not work in all Azure regions at release.
Optimize for unknown
مفهومی در SQL Server وجود دارد به نام parameter sniffing که شرح آن به صورت زیر است.
ابتدا رویه ذخیره شده زیر را در نظر بگیرید:
create procedure test (@pid int)
as
select * from Sales.SalesOrderDetail
where ProductID = @pid
اما این نوع کوئریها یک مشکل را نیز به همراه خود دارند. این plan تهیه شده به ازای اولین ورودی رویه ذخیره شده تهیه میشود (parameter sniffing) و الزامی ندارد که برای دومین ورودی و فراخوانیهای بعدی، بهترین plan باشد.
برای حل این مشکل راههای زیادی هست:
الف) انتساب پارامترهای یک رویه ذخیره شده به متغیری محلی
create procedure test (@pid int)
as
Declare @mpid int
Set @mpid = @pid
select * from Sales.SalesOrderDetail
where ProductID = @mpid
ب) استفاده از گزینه RECOMPILE که سبب خواهد شد به ازای هر ورودی یک plan بهینه تهیه شود. این مورد مصرف CPU بالایی را به همراه خواهد داشت.
ج) راه حل ارائه شده در SQL Server 2005
استفاده از روش الف به علاوه اضافه کردن گزینه کمکی زیر به انتهای اسکریپت فوق
OPTION (OPTIMIZE FOR(@pid = 544))
در اینجا فرض بر این است که میدانیم pid=544 بسیار مورد استفاده قرار خواهد گرفت، بنابراین این معرفی را به موتور بهینه ساز SQL Server ارائه خواهیم کرد.
د) راه حل ارائه شده در SQL Server 2008
با استفاده از Optimize for unknown که در اس کیوال سرور 2008 معرفی شده است، مزیت استفاده از کوئریهای پارامتری همانند استفاده مجدد از plan تهیه شده، حفظ گشته اما این plan تهیه شده اولیه بر اساس اولین مقدار پاس شده، تهیه نگردیده و حالت عمومیتر و بهینهتری را برای اکثر مقادیر پاس شده خواهد داشت.
create procedure test (@pid int)
as
select * from Sales.SalesOrderDetail
where ProductID = @pid
OPTION(OPTIMIZE FOR (@pid UNKNOWN))
جهت مطالعه بیشتر (+ و + و +)
نحوه پیکربندی و استفاده از PostgreSQL در Entity Framework Core
Npgsql has an Entity Framework (EF) Core provider. It behaves like other EF Core providers (e.g. SQL Server), so the general EF Core docs apply here as well. If you're just getting started with EF Core, those docs are the best place to star
Development happens in the Npgsql.EntityFrameworkCore.PostgreSQL repository, all issues should be reported there
Node.js Tools 1.0 for Visual Studio (NTVS) is now available for download! NTVS is a free, open source extension for Visual Studio 2012 and Visual Studio 2013 that turns Visual Studio into a Node.js IDE. NTVS 1.0 supports the free Visual Studio Community and Visual Studio Express for Web editions, as well as Visual Studio Professional and higher