وحید نصیری وحید نصیری
مزیت‌های استفاده از رویه‌های ذخیره شده؛ واقعیت یا توهم؟!
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: دو دقیقه

متن زیر یک سری نکات و یا شاید توهماتی را مطرح می‌کند که در مورد رویه‌های ذخیره شده در اس کیوال سرور رایج هستند.

1- رویه‌های ذخیره شده در مقابل SQL Injection مقاوم هستند. کوئری‌های Ad hoc همیشه این آسیب پذیری را به همراه دارند.
نادرست است! رویه‌های ذخیره شده‌ای که رشته‌ها را به صورت پارامتر دریافت کرده و آن‌ها را به صورت یک عبارت sql اجرا می‌کنند، آسیب پذیر هستند. اگر هنگام استفاده از کوئری‌های Ad hoc از پارامترها استفاده شود، در برابر حملات SQL Injection مصون خواهید بود.

2- execution plan رویه‌های ذخیره شده کش می‌شوند اما این Plan برای کوئری‌های Ad hoc هر بار محاسبه و تولید می‌گردد.
نادرست است! اس کیوال سرور تا این اندازه بی هوش نیست! اگر execution plan ایی موجود باشد حتما استفاده خواهد شد و برای موتور اس کیوال سرور اصلا اهمیتی ندارد که کوئری در حال اجرا از یک رویه ذخیره شده صادر شده است یا از یک کوئری Ad hoc . رویه‌های ذخیره شده پیش کامپایل شده نیستند و مانند تمامی کوئری‌های دیگر در زمان اجرا کامپایل می‌شوند.

3- زمانیکه از رویه ذخیره شده استفاده می‌کنید همه چیز را در یک مکان به صورت متمرکز و مجتمع خواهید داشت (مدیریت بهتر)
نادرست است! در یک مکان متمرکز در اختیار شما نیستند. برنامه جای خود را دارد و رویه‌های ذخیره شده در دیتابیس در جای دیگری قرار دارند و برای مثال اگر قرار باشد یک پارامتر را به رویه ذخیره شده خود اضافه کنید، کدهای شما نیز باید تغییر کنند.

4- می‌توان از یک رویه ذخیره شده استفاده مجدد کرد (در نقاط مختلف یک کد) و اعمال تغییرات تنها در یک مکان (دیتابیس) باید صورت گیرد.
هر چند این مورد درست است، اما باید دقت داشت که اگر چندین برنامه از این رویه ذخیره شده استفاده می‌کنند نباید تغییرات شما باعث از کار افتادن سایر برنامه‌ها شوند.

5- می‌توان رویه ذخیره شده را بدون نیاز به توزیع مجدد برنامه تغییر داد.
این مورد تا حدودی صحیح است. اگر تنها بحث بهینه سازی و امثال آن مطرح باشد صحیح است اما اگر واقعا نیاز به تغییر یک کوئری در رویه ذخیره شده وجود داشته باشد به احتمال زیاد برنامه نیز باید دستخوش تغییراتی گردد تا این دو با هم هماهنگ شوند.

نظر شما چیست؟


‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۰۱:۴۱
۲۶۴۴
۷
SQL Server
مطالب مشابه
  • #
    مهمان مهمان
    ‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۰۲:۲۳
    سلام استاد نصیری
    در رابطه با نکته دوم من فکر کنم که هر بار هر کوئری میاد پارس بشه و بعد براش Execution Plan در نظر گرفته بشه. یادمه خودم امتحان کردم استور سریعتر بود. به شخصه ترجیح میدم که داخل برنامم از دستورات اس کیو ال استفاده نکنم چون مدیریتش سخت تره
    ممنون از مطلبتون
  • #
    مهمان مهمان
    ‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۰۳:۴۴
    مرسی از مطلبتون،
    منظورتون از کوئری‌های Ad Hoc کوئری‌هایی ست که در زمان اجرا ساخته می‌شوند یا در سمت کلاینت قرار دارند هست؟ یا تعریف دیگری دارد؟
    در مورد نکته‌ی دوم من این مطلب رو جایی خوندم که کوئری‌های Ad Hoc هر بار کامپایل میشن و Exec Plan شون بدست میاد و.... البته اون مطلب در مورد SQL Server 2000 بود.
  • #
    وحید نصیری وحید نصیری
    ‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۰۴:۱۵
    بله. Ad hoc query به کوئری‌هایی گفته می‌شود که توسط برنامه بر اساس نیاز آنی کاربر ساخته می‌شوند.
    http://it.toolbox.com/wiki/index.php/Ad_hoc_query

    البته اینجا بیشتر منظور همان کوئری‌های مخلوط با سورس کدهای شما ست.
  • #
    مهمان مهمان
    ‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۱۲:۱۶
    من شخصاً ترجیح می‌دهم به جای استفاده از SP و امثالهم از یک ORM خوب مثل NHibernate استفاده کنم. این طوری می‌توانم بخش زیادی از منطق را در داخل زبان مورد استفاده مثل C#‎ پیاده‌سازی کنم.
  • #
    مهمان مهمان
    ‫۱۵ سال و ۳ ماه قبل، چهارشنبه ۱۴ مرداد ۱۳۸۸، ساعت ۱۵:۱۹
    منم با آقای محبی موافقم.با این تفاوت که LINQ رو NHibernate ترجیح میدم.

    با SP ها درسته که تقرایبا کار ها مدیریت بهتری دارن ولی مثلا زمانی که لازم باشه SP رو تغییر بدید باید خیلی چیز ها باز بینی بشن.

    این مشکل وقتی با DataSet ها کار می کنی بیشتر هم میشه.

    موفق باشید
  • #
    وحید نصیری وحید نصیری
    ‫۱۵ سال و ۳ ماه قبل، پنجشنبه ۱۵ مرداد ۱۳۸۸، ساعت ۱۸:۰۱
    چند مورد را در مورد نکته دوم جهت تکمیل بحث اضافه کنم:

    در اس کیوال سرور 2000 اگر از ad hoc کوئری استفاده شود احتمال recompile شدن بسیار زیاد است اما این مورد از اس کیوال سرور 2005 به بعد به شدت بهبود یافته. برای مطالعه بیشتر
    Execution Plan Caching and Reuse
    http://technet.microsoft.com/en-us/library/ms181055%28SQL.90%29.aspx

    نکته مهمی که در ad hoc کوئری‌ها ممکن است سبب recompile شدن plan اجرایی آن شود بحث تغییر نوع یا اندازه‌ی پارامترهای مورد استفاده است. اگر این موارد به صورت صریح ذکر شوند و از پارامترهایADO.Net استفاده شوند، تشخیص نوع و اندازه پارامترها برای اس کیوال سرور بسیار ساده شده و حتما از کش بجای recompile استفاده خواهد کرد. برای مطالعه بیشتر:
    Parameters and Execution Plan Reuse
    http://technet.microsoft.com/en-us/library/ms175580%28SQL.90%29.aspx
    دقیقا همین نکته را اگر از Nhibernate‌ استفاده می‌کنید نیز باید رعایت کنید:
    NHibernate queries & sql server execution plans
    http://testdrivendevelopment.wordpress.com/2009/03/10/nhibernate-queries-sql-server-execution-plans/
    خلاصه این مقاله به این صورت است که اس کیوال سرور را وادار نکنیم که از recompile به جهت مشخص نبودن طول یا اندازه پارامترها، هر بار استفاده نماید.
  • #
    مهمان مهمان
    ‫۱۵ سال و ۲ ماه قبل، یکشنبه ۱۸ مرداد ۱۳۸۸، ساعت ۱۳:۰۵
    سلام
    به چه مبحث خوبی اشاره کردید.
    یکی دیگر از نکاتی که مهم است ، از یکپارچگی درآمدن تیم پیاده سازی است که از لحاظ مدیریت پروژه بسیار مهم است. بدین معنی که اعضای تیم پروژه باید مفهوم جدیدی به نام sp را آموزش ببینند که این امر باعث کاهش سرعت توسعه می شود در حالی که با استفاده از یک ORM برنامه نویسان در لایه DAL با همان زبان برنامه نویسی که در لایه BLL برنامه می نویسند کار می کنند.
    از طرف دیگر استفاده از sp ممکن است شما را به استفاده از پایگاه داده خاصی محدود کند.