پرس و جوی بانک اطلاعاتی
برنامهنويسان پايگاه داده، عموما در نوشتن پرسوجوها دچار اشتباهات سادهاي ميشوند كه اجتناب از آنها ميتواند كارآيي كلي برنامه و سرعت پاسخگويي را افزايش دهد.
با دقت اين نكات را بخوانيد تا مطمئن شويد كه قرباني اين اشتباهات نشدهايد و نخواهيد شد.
كليد واژه:
پرسوجو، كارآيي، پاسخگويي، آزمون
Query, MS SQL Server, Select, performance, responsiveness, test
با توجه به رشد سریع و روزافزون حجم دادهها در پایگاه دادههای SQL Server و انتظار كاربران براي سرعت پاسخدهي دهمثانيهاي سيستمها، این مساله مهم پیش رو قرار ميگيرد كه باید از نوشتن پرسوجوهای[1] ضعیف دوري كرد. در مقاله حاضر ده خطاي متداول مربوط به نوشتن پرسوجو را مطرح میكنیم تا با بهكارگیری آنها از خطري كه در كمين پرسوجوهاست اجتناب كنيد. با دقت مطالب زیر را بررسی كنید تا مطمئن شوید كه قربانی این اشتباهات نشدهاید و برای اصلاح پرسوجوی خود نیز این توصیهها را به كار ببندید.
1- مدل دادهها و پرسوجوهای بعدی
اگر زمانی كه مشغول ساخت مدل دادهها[2] هستید درباره چگونگی دسترسی به دادهها فكر نكنید، ممكن است نتيجه كار پرسوجویی بدفرم و سنگين شود. این مساله ممكن است باعث به وجود آمدن JOINهاي غیرضروری شود كه كد را بیش از اندازه پیچیده میكند و به اجرای برنامه صدمه میزند.
برای اصلاح این مساله به پرسوجوهایی فكر كنید كه برای دسترسی به دادهها مورد نیاز میباشند. اگر نحوه دسترسي در این مرحله از فرآیند پرسوجو واضح نباشد، اين مساله باعث سختتر شدن كد و در نتيجه، پیچیدهتر شدن طراحی پايگاه داده خواهد شد. در اين صورت بايد به اصلاح و سادهسازي پرسوجو پرداخت.
در ارتباط با این نكته، اگر فردی هستید كه با ديدن بهتر ميتوانيد مسايل را درك كنيد، حتما مدل دادهها را چاپ كنید یا مدل خود را در ابزار مدلسازی دادههاي مورد استفاده خود مرور كنید.
2- بهترین تكنیكها كداماند؟
بحث بر سر استفاده از cursor يا منطق مبتني بر set[3] است. عقل سلیم حكم ميكند كه برای دسترسی به تمام دادهها از منطق مبتني بر set استفاده شود. من نیز این مساله را عنوان يك قانون كلي ميپذيرم. استفاده از cursor وقتي كه منطق مبتني بر set انتخاب درستی میباشد، كارآيي پرسوجوها را نيز قرباني ميكند. SQL Server برای منطق مبتني بر set طراحی شده است و باید در بیشتر مراحل پردازش دادهها از اين روش استفاده شود.
البته، در این وضعیت منطق مربوط به cursor نسبت به منطق مبتني بر set بهتر كار میكند. نتيجه اين كه ، از این اطلاعات برای تعیین نوع پردازشی كه در حال اجرا است و برای انتخاب بهترین تكنیك مورد نیاز استفاده كنيد.
3- هنوز به روش قدیمی كار ميكنيد؟
SQL Server 2005 مجموعهای كامل و جدید از فرصتها را برای پرسوجو فراهم میكند. البته، هنوز ميتوان شیوههاي قدیمی را به كار بست، اما زمان آن فرارسیده تا از آخرین امكانات بهره ببريم. روش مديريت خطا با TRY…CATCH یكی از اولین تكنیكهايي است كه باید در كد خود به كار ببندید. موارد دیگری كه باید در نظر بگیرید common table expressions است كه با سلسله مراتب به كار گرفته میشود. مورد آخر این است كه باید قابلیتهای موتور پایگاه داده را با استفاده از CLR توسعه دهید. این سه تكنیك به طرز چشمگيري روش كار شما با Server SQL را تغيير ميدهند و این خود نكتهای است كه بحث مفصلتری را میطلبد.
4- آیا به اینجا نگاهی انداختهاید؟
قبل از بهكارگیری كد حتما از فرد ديگري بخواهيد آن را بهدقت مرور كند. مرور كد و بهخصوص نقشه پرسوجو[4] برای اطمینان از بهكارگیری شاخصهای صحیح ضروری میباشد. چنین پرسوجوی مرورشدهاي، معمولا، همان طور كه انتظار میرود اجرا خواهد شد.
نكته این جاست كه یكی از سادهترین ابزارها برای اطمینان از صحت كد لزوم بازبینی آن توسط شخص دیگری است. این روش میتواند هم برای برنامهنویس و هم برای همكار او تجربهای باشد تا با چگونگی مواجهه با چنين مسايلي توسط برنامهنویسان دیگر و مدير پايگاه داده[5] آشنا شوند. این روش را میتوان به عنوان ابزاری برای مبادله ایدهها و اصلاح مهارتهای یكدیگر به كار بست.
5- يك اشتباه كلاسيك
نوشتن يك عبارت SELECT * با این گمان كه تغییری در جدول ایجاد نخواهد شد، اشتباهی قدیمی است. حتی در سادهترین شرایط نیز جدول ممكن است بناچار تغییر كند و این مساله مرور كد را برای اطمینان از نبود ستونهای اضافی ایجاب مینمايد. وضعيت بدتر این است كه منتظر وقفه یا اشكالی در برنامه شوید و بعد به تصحيح آن بپردازید. بهترین كاری كه میتوان انجام داد گنجاندن ستونهایی است كه در پرسوجو مورد نیاز هستند و تنها تغییر همان ستونها در صورت بوجود آمدن تغيير.
روز خود را با جستجو در كد، همانند فردي بيخانمان كه در خرابههاي يك ساختان جستجو ميكند خراب نكنيد.
6- هیچ توضیحی نمينويسم!
متاسفانه اكثر كدهایی كه نوشته میشود، یا توضیح كمی دارند و یا اصلا در آنها از توضيح استفاده نشده است با اين شرايط اعمال تغییرات حتی براي برنامهنویس يا مدير پايگاه دادهاي كه برنامه را نوشتهاند كاري بسيار سخت(ترسناك) خواهد بود[6]. نوشتن توضیح برای كد حقیقتا فرآیندی است سریع و بیزحمت كه برای درك و تغییر كد به شیوهای امن و مناسب برای برنامهنویساني كه در آینده با كد سروكار خواهند داشت، امری ضروری میباشد.
7- حتما، آن را تست خواهم كرد!
برنامهنویسان و مديران پايگاه داده غالبا طرفدار آزمونهاي ساده هستند و آزمونهاي سخت را قبل از انتشار كد برای محیط تولید به كار نمیبرند. علاوه بر اين، در زمان توليد نرمافزار دادههايي كه بوجود ميآيند به هيجعنوان به پای محیطهای استفاده و كاربري نمیرسند. میتوان گفت كه پرسوجوهای ساده با صدها یا حتی هزاران ركورد نیز به خوبی كار میكنند اما در مرحله كاربري به اين صورت نخواهد بود. هیچ راهي بهتر از این كه كد خود را در محیط آزمایش در برابر ميلیونها ركورد در جداول پراكنده شده[7] آزمایش كنید، وجود ندارد. این كار باعث حصول اطمینان از عملكرد مورد انتظار از پرسوجو میشود.
8- آن را به من بده، جدي ميگويم!
نوشتن يك عبارات SELECT بدون شرط WHERE و انتظار از لايه مياني يا انتهايي برنامه كاربردي[8] برای پردازش داده به شیوهای كارآمدتر از SQL Server اشتباه محض میباشد. SQL Server برای فرآیند جستجو طراحی شده است و این كار را به شیوهای بسیار كارآمد انجام میدهد. انتقال مجموعهای بزرگ از دادهها تنها باعث جلوگیری از عملكرد كارآمد سیستم و شبكه میشود و حتي آن را تا مرحله اشباع میكشاند. از فیلتر شدن مجموعه دادههايتان، تا جایی كه ممكن است، اطمینان حاصل نمایید. این كار باعث جلوگیری از تبعات اجرایی میشود.
9- از view استفاده كنيد!
دیدها نیاز به ساده كردن كد را برای پرسوجوهای پیچیده برآورده میكنند. دیدها اغلب برای كمك به كاربران حرفهای برای پرسوجوی پایگاه دادهها به كار میروند. متاسفانه استفاده بیش از حد از یك چیز خوب میتواند منجر به تاثیرات مخرب شود. دید فقط یك عبارت SELECT است و عبارت SELECTمربوط به آن زماني كه ديد را اجرا ميكنيد، اجرا ميشود. استفاده از دیدها را محدود و از ايجاد ديدهاي تودرتو خودداري كنید. بسياري از مواقع ميتوانيد با يك رویه ذخيرهشده[9] كه به آن پارامترهای مورد نیاز را ارسال كردهايد به نتيجه دلخواه دست يابيد.
10- نه! ، من اين كد را ننوشتهام.
ما همه مسلما اشتباه میكنیم. اين موضوع بسيار بديهيست كه آخرین سیستمی كه روی آن كار كردهايم از اندوختههای پروژه جاريمان بهرهمند شده است. بنابراین آموختههايتان را يادداشت كنید تا با دیگر اعضای تیم به اشتراك بگذارید. هر زمان كه مجالی به دست آوردید به سیستمهای قبلی بازگردید و با دانشهاي جديد كه كسب كردهايد آنان را بهبود بخشيد.
نتیجه
اگر در مورد پرسوجوهايتان مرتكب يكي از این اشتباهات شدید، آن را تشخیص دهید و برای رفع آن تلاش كنید. البته، حرف زدن از عمل كردن سادهتر است، اما تصحیح اشتباه سازمان را منتفع و اعتبار برنامه را بيشتر میكند. به عنوان نتيجهگيري عملي از اين مقاله، شروع به ساخت راهنمای شخصی براي برنامهنويسي كنید تا از آن برای پروژههای جاری و آیندهتان استفاده نماييد.
[1] query
[2] Data modeling
[3] set-based logic
[4] Query plan
[5] DBA
[6] ويراستار: منظور نويسنده(به احتمال قوي)، برنامهاي ميباشد كه كاربران از آن در حال استفاده ميباشند و بايستي بدون اينكه هيچ خللي در روند اجراي بوجود آيد، تغييرات اعمال شوند و بازهم به اين نكته توجه كنيد كه برنامههايي كه از پايگاههاي داده استفاده ميكنند، به طور معمول داراي حداقل 5 كاربر ميباشند(كه اگر 10ها برابر نباشد)
[7] Fragmented
[8] منظور لايههاي web server و مرورگر است. - ويراستار
[9] Stored procedure
امیدوارم از این مطلب بهره لازم را برده باشید