ورود

View Full Version : ارسال دستور select به عنوان ورودی procedure


razaghi
پنج شنبه 09 تیر 1384, 13:51 عصر
چطور می توانم یک دستور select را به عنوان ورودی به procedure بدهم؟
Krubnik
پنج شنبه 09 تیر 1384, 14:15 عصر
شما می توانید یک متغییر از نوع Varchar معرفی کنید و دستور Select رو با فرمت Text در اون متغییر قرار دهید سپس متغییر را به عنوان وردوی به تابع پاس کنید.
در تابع هم دستور Select رو بصورت زیر اجرا کنید:
Exec(@SelectCommand)
AminSobati
پنج شنبه 09 تیر 1384, 23:49 عصر
اگر چه راه حلی که ارائه شد صحیحه اما منطق این کار در چیه؟ چنین عملی نه تنها از لحاظ Security مشکل داره بلکه از قابلیت Stored Procedure استفاده نشده و هر بار میبایست Query کامپایل بشه!
m-khorsandi
دوشنبه 27 تیر 1384, 09:09 صبح
آقای ثباتی میشه منظورتون رو در مورد Security روی این دستور بفرمائید و اینکه در مورد هر بار کامپایل شدن
آیا روی سرعت تائیر داره یا منظورتون مورد دیگه ایی هست؟

ممنون.
AminSobati
سه شنبه 28 تیر 1384, 02:05 صبح
دوست عزیزم انجام این کار باعث میشه دیتابیس شما مستعد SQL Injection باشه. در این مورد اگر جستجو کنین مطالب زیادی در اینترنت (و حتی همین سایت) پیدا خواهید کرد. به طور خلاصه اینکه اگر دستور Select شما قسمتی رو از User بگیره تا تکمیل بشه، کاربر میتونه مقادیر خاصی رو وارد کنه که عملکرد دستور Select عوض بشه. این موضوع در مورد Web Applicationها حساسیت بیشتری داره.
و اما در مورد کامپایل شدن، هر Query چه در SP باشه و چه از طریق ()EXEC اجرا بشه براش Execution Plan بدست میاد. اما در SP چون ثابت هستش، این Plan در دفعات بعدی هم استفاده میشه و Valid (معتبر) به حساب میاد. در حالیکه Plan بدست آمده از طریق ()EXEC بلافاصله Invalid میشه و در اکثر موارد، Plan مورد استفاده مجدد قرار نمیگیره (لذا Recompile نیاز هست تا دوباره Plan بدست بیاد). اگر تعداد کاربرها زیاد باشه و این روش به طور غیر ضروری مورد استفاده قرار بگیره، اصطلاحا Performance Penalty خواهد داشت(البته کاهش سرعت در صورتی محسوس هست که این کار بسیار زیاد در مدت زمان کم اتفاق بیافته). اما استفاده از sp_executesql شانس استفاده مجدد از Plan رو بیشتر میکنه. این دستور مانند ()EXEC عمل میکنه با این تفاوت که در sp_executesql قسمتهای ثابت به SQL Server معرفی میشن تا Plan براشون دائمی باشه اما همچنان ریسک Security وجود داره.
Kamyar.Kimiyabeigi
سه شنبه 28 تیر 1384, 07:45 صبح
آقای ثباتی اگر درست متوجه شده باشم منظور شما اینه که ما قسمتهای ثابت select رو در sp بزاریم و قسمتهای متغیر رو به عنوان پارامتر پاس کنیم اگر درسته پس 1 سوال در واقع میشه گفت که بیشتر قسمتهای یک select ممکنه متغیر باشه مثل نام جدول و نام فیلدهای مورد select و همینطور where condition
پس باید چی کار کرد؟
m-khorsandi
سه شنبه 28 تیر 1384, 13:12 عصر
در ادامه بحث پیشنهاد میکنم این فایل رو مطالعه کنید :
AminSobati
پنج شنبه 30 تیر 1384, 00:01 صبح
نه کامیار جان، نام جدول و فیلدها نباید متغیر باشند. برای هر Query باید یک SP یا View (بسته به نیاز) بسازین. شما که قصد ندارین تمام Query ها رو با یک SP جواب بدین!؟
Kamyar.Kimiyabeigi
شنبه 01 مرداد 1384, 08:13 صبح
آقای ثباتی جسارتا اونوقت این جوری فکر کنم تعداد sp زیاد بشه فکر کنم بهترین راه همونی باشه که خودتون گفتین یعنی به مرور زمان و بر اساس تجربه بفهمیم که کدوم راه درسته و کدوم راه غلط

موفق باشین
AminSobati
شنبه 01 مرداد 1384, 23:27 عصر
کامیار جان قطعا شما هم Performance بالا رو ترجیح میدین. اگر چه ممکنه تعداد SPها یا Viewها زیاد بشه اما اصولا یک برنامه نویس مشکلی با این مسئله نداره :)
rezaei manesh
یک شنبه 28 آبان 1385, 14:38 عصر
من تا به حال فکر می کردم هر چقدر sp من چند منطوره تر باشه بهتره مثلا برای چند 6-5 کویری از یک sp استفاده می کردم
اما با توجه به فرمایش اساتید باید تعداد پروسیجر ها مو خیلی بیشتراز این حرف ها درست کنم
درسته دیگه مقاله شما رو هم گرفتم برم مطالعه کنم