با وجود رشد مداوم و قابل توجه داده ها در بانکهای اطلاعاتی نرم افزار SQL server که با زمانهای پاسخ دهی مجدد مورد انتظار کاربران همراه شده، اجتناب از پرس و جوهای نوشته شده)مکتوب( حتی تا حد ناچیز نیز بحرانی و حساس است. در این موضوع مهم، برای اجتناب از خطاها، ده خطای مرسوم در طراحی پرس و جو را بطور خلاصه بیان می نماییم.
برای اینکه مطمئن شوید که در دام این خطاها نمی افتید، به آنها نگاهی بیندازید و به توصیه ها به عنوان وسیله ای برای اصلاح پرس و جوهایتان توجه کنید.
لیست ده خطای مهم
۱- مدل داده ها و پرس و جوهای مابعد
زمانی که شما مدل داده هایی را می سازید که از پرس و جوهای بزرگ منتج می شوند، فکر نکنید درمورد اینکه چطور به آن داده ها دسترسی پیدا کنید. شما ممکن است فرمانهای غیر ضروری داشته باشید که آن کار رمز نویسی و آسیب پذیر را بیش از حد پیچیده می کنند.
برای اصلاح کردن این مسئله، بر درمورد پرس و جوهایی فکر کنید که برای دست یابی به داده ها لازمند. اگر در این مرحله از پردازش پرس و جو واضح نیست، حتی کد نویسی نیز مشکلتر خواهد بود. اینکه طراحی بانک اطلاعاتی ممکن است بیش از حد پیچیده باشد و برای بهبود عملکرد پرس و جو می تواند ساده نیز باشد جزء احتمالات هستند.
نکته، اگر شما فرد متفکری هستید، برای منتشر کردن مدل داده ها یا مرور کردن مدل اینترنتی به ابزار مدل سازی داده ها که خودتان انتخاب کرده اید مطمئن باشید. این کار باید زمان کد نویسی و درجه دقت شما را بهبود دهد.
۲- بهترین تکنیک چیست؟
این نشانگری آشکار در برابر بحث منطقی معیینی است. حکمت متعارف برای دستیابی به تمام بانکهای اطلاعاتی استفاده از منطق مشخصی را بیان می کند. بطور کلی، من موافقم که این بهترین قانون کلی است. زمانی که منطق مشخص شده گزینه صحیح است، استفاده کردن از نشانگرها همچنین می تواند جریمه های کاری مهمی را اعمال کند. نرم افزار SQL server بخاطر منطق مشخصی طراحی میشود و باید در بیشتر پردازشها استفاده گردد.
در طرف دیگر سکه، این نمونه )مثال( نشانه گر قرار دارد. در این حالت، منطق نشانه گر بهتر از منطق تعیین شدده اجرا میشود. دوری از این اطلاعات برای تعیین نوع پردازشی که شما انجام می دهید می باشد و تکنیکی را انتخاب کنید که به بهترین شکل متناسب با نیازها می باشد.
۳- انجام دادن آن به روش قدیمی
همراه با نرم افزار SQL server2005 مجموعه جدید و کاملی از فرصتها برای پرس و جوهایتان پدید می آید و درنتیجه، انجام کارها به روش قدیمی ممکن است هنوز هم عملی باشد، ولی شاید وقت آن باشد که آخرین گزینه ها مورد نظر قرار گیرند.
روش خطا یابی ترای، کچ (TRY, CATCH) یکی از اولین تکنیکهایی است که شما باید آن را در کد نویسیهایتان بپذیرید.
ملاحظات بیشتر شامل اصطلاحات جدولی مرسوم برای کار کردن براساس سلسله مراتب هستند و آخرین ملاحظه گسترش ظرفیتهای موتور بانک اطلاعاتی رابطه ای می باشدCLR). این سه تکنولوژی بصورت قابل توجهی در حال تغییرند بطوری که شما می توانید با نرم افزار SQL server کار کنید و آنها تنها راس توده ای یخی هستند.
۴- آیا شما نگاهی در اینجا می اندازید؟
مرور کد گذاریهایتان و زمان بندی یک ارزش یابی کاری ضرورتی است که قبل از کد گذاری گسترش می یابد. برای اطمینان حاصل کردن از اینکه شاخصهای مناسبی استفاده شوند و اینکه پرس و جو همانطور که انتظار می رود عمل کند، مرور کد گذاریتان و بویژه طرحهای پرس و جو مهم و حیاتی به نظر می رسد.
نکته، یکی از ساده ترین روشها برای اطمینان حاثل کردن از کد گذاری که دقیق نیز می باشد، داشتن دیدگاهها و نظرات دیگری برای بررسی آن است. این کار می تواند یک تجربه یادگیری برای هر دو توسعه دهنده و همکارش باشد که ببینند مدیران بانک اطلاعاتی و توسعه دهندگان دیگر چگونه با مسائل برخورد می کنند. این همچنین روشی برای مبادله کردن ایده ها به منظور بهبود مهارتهای یکدیگر است.
۵- این پرس و جوی کلاسیک است
صدور دستور سلکت SELECT، فکر کردن درمورد اینکه جدول تغییر نخواهد کرد، یک خطای کلاسیک در طراحی پرس و جو می باشد. حتی در ساده ترین حالت، ناچار جدول تغییر می کند، و اجازه می دهد که شما کد گذاری را بررسی کنید تا اینکه مطمئن شوید که ستون دیگری اضافه نشده است. یا باز هم بدتر، شما باید منتظر باشید کاربردی نغض شود و بعد آن مسائل و موضوعات را تعیین کنید. بهترین کار صرفا قرار دادن ستونهای لازم در پرس و جوهای شماست و تغییر دادن آنها بطور ضروری است. با جستجو کردن در بین کدها روز خودتان را خراب نکنید.
۶- من هیچگونه توضیح وتفسیری ندارم!
متاسفانه بیشترین کد نویسییی که من مشاهده می کنم مقدار اندکی یا هیچگونه تفسیری ندارد. بنابراین، ایجاد کمترین تغییرات حتی برای توسعه دهنده و یا مدیر بانک اطلاعاتی که در اصل این کار)برنامه کاربردی( را توسعه داده است وظیفه ای خطیر می باشد. تفسیر کردن کد نویسیتان به درستی یک فرایند سریع و بی زحمت است، و فهمیدن و تغییر دادن کد نویسی به روش مطمئن و به موقع برای توسعه دهندگان آینده خطرناک است.
۷- قطعا من آن را امتحان خواهم کرد
تعداد کمی از توسعه دهندگان و مدیران بانک اطلاعاتی آزمایش ساده را دوست دارند و آنها از آزمایش سخت پیش از ارائه کد به محیط تولید خوششان نمی آید.
بعلاوه، در اصطلاحات سخت افزاری و انواع داده ها، محیطهای توسعه معمولا به اندازه مقیاس محیطهای تولید نیستند. گفته میشود، پرس و جوهای ساده با یکی دو صد یا حتی چندین هزار رکرد خوب عمل می کنند اما در تولید که آن مورد نیست.
برای اینکه مطمئن شوید پرس و جوها همانطور که انتظار می رود عمل می کنند، هیچ روشی بهتر از آزمایش در مقابل میلیونها رکرد در جداول تکه تکه شده در محیط آزمایش برای تهیه کردن پرس و جوهایتان وجود ندارد.
۸- اجازه دهید آن را داشته باشم، منظورم آن است!
صدور دستورات سلکت SELECT بدون بند WHERE و انتظار داشتن از نرم افزار نهایی بانک اطلاعاتی و ردیف میانی (middle tier, front end) برای پردازش کردن داده ها به روشی موثرتر از نرم افزار SQL server معامله ای بادوام است. نرم افزار SQL server برای پردازش پرس و جو طراحی میشود و این کار را بطور بسیار موثری انجام می دهد. انتقال مجموعه های بزرگی از داده ها تنها قصد دارد سیستمها و شبکه ها را تا جایی در باطلاق فرو ببرد که آنها غرق و نابود گردند. مطمئن باشید برای غربال کردن مجموعه داده هایتان تا حد امکان از مفاهیم و دلالتهای کاری اجتناب کنید.
۹- لطفا من یک پرس و جو با یک نما می خواهم
نماها نیاز ساده کردن کد نویسی را برای پرس و جوهای پیچیده برآورده می کنند. آنها )نماها( اغلب برای کمک کردن به پرس و جوی کاربران پیشرفته در بانک اطلاعاتی استفاده می شوند. متاسفانه، مقدار خیلی زیادی از یک چیز خوب می تواند کار یا عملکردی را به شدت تحت تاثیر قرار دهد.
آن نما به سادگی یک دستور سلکت SELECT است و دستور سلکت نما زمانی باید صادر شود که دستور سلکت شما صادر میشود. استفاده از نماها را محدود کنید و مانع از این شوید که آنها دیگر نماها را پرس و جو کنند. یا، برای پرس و جو کردن از داده ها، یک پروسه و رویه ذخیره شده ای را ایجاد کنید و برای انجام این برنامه کاربردی و نیازهای کاربران، از پارامترهای مورد نیاز استفاده نمایید.
۱۰- نه، این کد گذاری من نیست
همه ما اشتباهاتی را مرتکب می شویم، و آخرین سیستمی که ما بر روی آن کار کرده ایم دارد از دانشی که ما در جریان این پروژه بدست می آوریم بهرمند میشود.
درنتیجه، آیتمهایی را که شما یاد گرفته اید یادداشت کنید و آنها را با تیمتان به اشتراک بگذارید تا آن سازمان نیز سود ببرد.
زمانی که فرصتی پیدا می کنید، برگردید به آن سیستمهای قبلی و آنها را با دانشی که از این پروژه بدست آورده اید بهبود دهید.
نتیجه گیری
اگر شما دارید این خطاها یا دیگر خطاهایی را در پرس و جوهایتان مرتکب می شوید، آن خطا را تشخیص دهید و سعی کنید آن را برطرف سازید. شاید گفتنش آسان تر از انجام دادنش باشد اما اصلاح این مسئله به نفع آن سازمان و اعتبار برنامه کاربردی نیز می باشد. غیر از این موضوع، بیایید شروع کنید یک راهنمای کد نویسی شخصی بسازید و برای پروژه های جاری و آینده اتان از آن استفاده کنید.
