چگونه یک دیتابیس کارآمد داشته باشیم
ابن گزينه در واقع به عنوان تنظيمي به جهت ياري رساندن به كاربر در هنگام تغيير نام آبجكتها در نظر گرفته شده ، تا تغييرات در نقاط ديگر نيز به صورت خودكار اعمال گردد . گو اينكه اين گزينه همچنان در بسياري موارد عدم كارايي خود را به نمايش ميگذارد و توصيه ميكنم ، حتي در حين طراحي نيز اقدام به غير فعال نمودن آن نموده و عطايش را به لقاي ژنده اش ببخشيد !
اين گزينه جداي از مفيد و يا غير مفيد بودنش در هنگام تحويل پروژه در حالت غير فعال قرار گيرد .
Compact and Repair
انجام اين عمليات به صورت دوره اي ، ميتواند به طور كامل موجب بهينه سازي عملكرد بانك اطلاعاتي شود ، فعال بودن اين گزينه موجب تاخير در هنگام بسته شدن بانك اطلاعاتي مي شود .
در واقع گزينه Compact بيشترين كار خود را از طريق كاهش حجم فايل و به تبع آن كاهش زمان دسترسي به فايل موجود بر روي هارد ديسك به انجام ميرساند ، كه اين اختلاف حجم خصوصاً در بانكهاي اطلاعاتي با حجم بالا نمود بيشتري پيدا ميكند .
پديده افزايش حجم , در واقع يك پديده درون ساختاري اكسس است كه با حذف و ضبط اطلاعات و اعمال تغيير در آنها به وقوع مي پيوندد . در اين فرآيند اطلاعاتي زائد به وجود مي آيد و در واقع در اين حالت فايل اكسس دچار افزايش حجمي كاذب ميشود كه الزاماً نه ناشي از ورود اطلاعات بلكه ناشي از پديده ای ذاتی از سوی اکسس ميباشد .
پس از عمليات حذف اطلاعات به همان اندازه افزايش حجم ناشي از افزودن اطلاعات ، از حجم فايل كم نخواهد شد . عمليات Compact ميتواند اين نقیصه را مرتفع نمايد .
توضيح : با ذخيره سازي بانك اطلاعاتي در حالت Encrypt شده ، عملاً فايل قابليت Compact شدن را به صورت ظاهري نخواهد داشت ( كاهش حجمي را ملاحظه نخواهيد كرد )
پي نوشت : به طور كلي الگوريتمهاي فشرده سازي قادر به كاهش حجم فايلهاي رمز نگاري شده نيستند و يا حتي در صورت كاهش ، اين حجم چشمگير نيست .
امید بود اكسس قابليت Repair را نیز به صورت منفرد داشت ، اين گزينه بسيار كاربردي تر و حياتي تر از Compact بوده و مشحص نيست كه چرا مايكروسافت اين دو را از قالب يك عمليات يكپارچه خارج ننموده است .
در واقع اكسس و ساختار آن به گونه اي است كه در حين كار اين احتمال وجود دارد كه دچار خطاهايي درون ساختاري شود كه در گذر زمان و به مرور مشكل ساز شوند ، عمليات Repair ميتواند بسياري از اين مشكلات جزئي را قبل از اينكه به يك مشكل جدي تبديل شوند پوشش دهد .
Analyze Performance
اين ابزار داخلي ميتواند پيشنهاداتي جهت عملكرد بالاتر بانك اطلاعاتي ارائه نمايد و برخي مشكلات ساختاري را مرتفع كند وليكن در ادامه ذكر يك نكته الزاميست :
در برخي مواقع پيشنهادات ارائه شده از سوي اين ، ابزار منطبق با فكر و ذهن برنامه نويس نيست ، از اين رو تمامي توصيه هاي اين ابزار را به عنوان يك راه حل قطعي فرض ننماييد ، خصوصاً در بخش ارتباطات بين جدولي بايد به پيشنهادات ارائه شده از سوي اكسس با دقت بيشتري عمل نماييد .
در مواقعی برنامه نويس به دلايلي خاص نياز ندارد كه بين برخي جداول ارتباطاتي منطقي را برقرار نمايد ، وليكن اكسس اين امر را ناديده نمي گيرد ، و آن را در ليست پيشنهادي خود لحاظ خواهد كرد .
بهبود عملكرد جداول به خودي خود منجر به افزايش عملكرد پرس و جوها نيز خواهد شد .
در ديگر بخشها و آبجكتها ، خوشبختانه اين ابزار ميتواند پيشنهاداتي مثمر ثمر را ارائه كند .
در برخي مواقع حتي اين امكان ميتواند منجر به بازساري نسبي يك فايل معيوب نيز گردد .
در حين فرآيند طراحي به صورت چندين باره از اين امكان استفاده نماييد و تا حد امكان به توصيه هاي آن عمل كنيد .
Front End / Back End الگوی طراحی
در واقع اين اصلاح به بانكهايي اطلاق ميشود كه در آن , اطلاعات ( جداول – Back End ) از ديگر آبجكتها جدا بوده و مابقي آبجكتها در فايلي ديگر نگهداري ميشوند ( پرس و جوها ، فرمها و ... – Front End )
طراحي بانك اطلاعاتي بدين روش منجر به كاهش ذاتي بخشي از كارايي خواهد شد ، كه با اتكا به توصيه هاي موجود ميتوانيد بخش اعظمي از اين كاهش كارايي ( سرعت ) را پوشش دهيد . امتيازاتي در اين فرآيند به دست خواهيد آورد ، به گونه اي كه وزنه اين نوع سبك طراحي را سنگين خواهد نمود .
طراحي بانك اطلاعاتي بدين روش منجر به :
افزايش ايمني اطلاعات
بهبود بسيار زياد در فرآيند ارتقاء نرم افزار
و پيروي از قواعد استاندارد تر طراحي در محيطهاي چند كاربره خواهد شد
استفاده از اين روش در الگوهاي كاري Client/Server الزاميست و در واقع اكسس انتخابي ديگر را در اختيار شما نخواهد گذاشت
نكته قابل ذكر جهت اولين قدم در مرتفع نمودن مشكلات ذاتي اين روش اين است كه تنها اقدام به Link نمودن جداولي در داخل Front End نماييد كه به صورت مشترك بين كاربران مورد استفاده قرار ميگيرند . جداولي كه حاوي اطلاعاتي منحصر به يك كاربر ميباشند را در بخش Front End قرار دهيد
گاهاً جداولي ميان كاربردي طراحي ميشوند كه نقش آنها تنها نگهداري موقتي اطلاعات در طي انجام يك پروسه ميباشد ، اين جداول تا حد امكان در سوي Front End قرار گيرند . ( به طور مثال ممكن است اطلاعاتي خاص به جدولي موقتي Append شوند وپس از اتمام عمليات اطلاعات جدول نيز حذف شود )
Progress Bar
اين نكته بيشتر نقش يك ترفند رواني را خواهد داشت تا يك بهينه سازي واقعي و برگرفته از مسائل روانشناسي است تا برنامه نويسي .
مغر انسان به گونه اي است كه هنگامي كه از پايان يك عمليات به طور تقريبي مطلع بوده و ميزان عمليات انجام شده را نيز مشاهده كند ، بسيار منطقي تر ! عمل نموده و آستانه تحملش بالاتر خواهد رفت ( به طور مثال به ايده وجود تايمر در كنار چراغهاي راهنمايي توجه كنيد ، زمان ، تغييري با حالتي كه تايمر وجود نداشته ، نكرده است وليكن گذر زمان آسان تر شده است )
بسياري طراحان اقدام به مخفي نمودن بخش Status Bar مي نمايند ، Progress Bar در واقع در داخل اين بخش گنجانده شده است ، Progress Bar در بسياري عمليات به نمايش در مي آيد ( همچون اجراي يك پرس و جو و ... )
كاربر هنگامي كه بازخوردی از سوي برنامه ، مبني بر اجراي دستور مورد نظرش داشته باشد ( نمایش Progress Bar ) ، تحمل گذر اين زمان براي او ساده تر بوده و در واقع برنامه از ديد او ، درخواستش را سريعتر به انجام ميرساند !
Relationships
طراحي بانك اطلاعاتي به صورت رابطه اي ( Relational ) در صورتي كه ارتباطات به درستي در نظر گرفته شوند موجبافزايش كارايي بسيار و بهينه سازي مطلق بانك اطلاعاتي ميشوند .
اهميت بررسي روابط اطلاعات به حدي است كه جا دارد زمان قابل توجهي را به آن اختصاص دهيد ، چرا كه مشکلات تغيير روابط در آينده ميتواند از دو منظر مورد بررسي قرار گيرد :
تغيير Realtionships موجود ميتواند منجر به ايجاد تغييراتي ناخواسته در پرس و جوها شود به گونه اي كه در صورت عدم تصحيح ، نتايج حاصله با خطا همراه باشند
در بسياري مواقع تغيير ارتباطات موجود ميتواند نيازمند اعمال تغييراتي خاص در جداول باشد
تذكر : قبل از هرگونه اعمال تغييرات اساسي در اين بخش ، از بانك اطلاعاتي خود نسخه پشتيبان تهيه كنيد ، برخي تغييرات ميتواند منجر به حذف اطلاعات شود ( گو اينكه اكسس اقدام به نمايش پيغام هشدار دهنده خواهد نمود )
بانك اطلاعاتي مبتي بر ارتباطات ميتواند بخشي از كد نويسي ها را تقليل داده و نظارت دقيقتري بر یکپارچگي اطلاعات داشته باشد امري كه انجام آن توسط كند نويسي غالبا ً بسيار دشوار تر ، كند تر ، ناكارآمد تر و ناايمن تر خواهد بود
تا حد امكان وظايفي را كه به صورت ذاتی در داخل اکسس به دوش بخش اطلاعات سپرده شده است به كد نويسي محول نكنيد .
Access 2003 Format
در نسخه 2003 اين قابليت وجود دارد كه فايل ، جهت سازگاري بيشتر با نسخه هاي پيشين ، اين پل ارتباطي را همچنان حفظ كند . در صورتي كه هدفي با عنوان دسترسي به فايل توسط نسخه هاي قديمي تر اكسس مد نظر نمي باشد ، توصيه ميگردد فايل خود را به فرمت 2003 تبديل نماييد ( تبديل به نسخه اصلي اكسس )
انجام اين امر منجر به افزايش نسبي كارايي ( در حد جزئي ) و خطا پذيري كمتر فايل خواهد شد .
در مجموع اين تغيير قوياً توصيه ميشود .
Primary Keys
تا حد امكان اقدام به تعيين نمودن كليد اصلي در داخل جداول نماييد .
انتخاب يك يا چند فيلد به عنوان كليد اصلي ميتواند منجر به افزايش سرعت بانك اطلاعاتي , در عمليات مبتني بر جستجو و انتخاب گردد .
انتخاب كليد اصلي در جداول يكي از گامهاي اساسي در جهت طراحي بانكهاي مبتنی بر روابط ميباشد .
در انتخاب كليد اصلي نهايت دقت را به كار برده و از انتخاب فيلدهايي با ماهيتي تكرار پذير ، به عنوان سوييچ اصلي خودداري كنيد .
Index
عملكرد شاخص در بخشهايي مشابه با Primary Key ميباشد . شاخص گذاري مناسب منجر به افزايش كارايي برنامه خواهد شد ، تا حد امكان با در نظر گرفتن نكات زير اقدام به شاخص گذاري بر روي فيلدها نماييد :شاخص گذاري بر روي فيلدهايي كه در بخش Criteria مورد استفاده قرار ميگيرند .شاخص گذاري بر روي فيلدهايي كه در فرآيند مرتب سازي مورد استفاده قرار ميگيرند .شاخص گذاري بر روي فيلدهايي كه در ارتباطات ( Relations) مورد استفاده قرار ميگيرند .البته ذكر يك نكته الزاميست : شاخص گذاري بيش از حد و غير اصولي به طور كاملاً معكوسي منجر به كاهش كارايي خواهد شد .
تا حد امكان از به كار گيري عملگرهاي Between , And ,… در فيلدهايي كه شاخص گذاري نشده اند ، اجتناب ورزيد
نکته : Primary Key سريعتر از Index عمل مي كند .
Data Entry Mode
در حالتي كه شما تنها قصد ورود اطلاعات را داريد ، بهتر است در حالت Data Entery عمل نماييد ، شما در حالت Data Entery عملاً بار ترافیکی شبکه را کاهش خواهید داد , ضمن اینکه افزايش سرعت غالباً قابل مشاهده خواهد بود .
IIf Function
تابع IIf و یا همان Immediate If , در بسیاری مواقع به عنوان جايگزين دستور If از سوي كاربران مورد استفاده قرار ميگيرد . تا حد امكان از اين تابع به جايگريني دستور If استفاده ننماييد .
يكي از دلايل كندي اين تابع ، تست و بررسي كليه شروط داخلي گنجانده شده در داخل اين تابع ميباشد ، در حالي كه در دستور If به محض تطابق يك شرط مابقي شروط مورد بررسي قرار نخواهند گرفت
Domain Aggregate Functions
به طور كلي توابع موجود در اين طيف بسيار كند ميباشند كه از آن دسته ميتوان به Dlookup , DMax و ... اشاره نمود . تا حد امكان از اين توابع استفاده نکنید .
استفاده از اين توابع در پرس و جوهايي كه جدول مورد نظر در آنها وجود ندارد ( در Query به صورت مستقیم شرکت داده نشده است ) ، به معناي واقعي يعني كاهش سرعت
Query Restrictions
در پرس و جوهايي مبتني بر جداول ارتباطي ، اگر شرط در سوي يك قرار دارد ( ارتباط يك به چند ) ، آن را در سمت چند اعمال كنيد ، نتايج را مقايسه كنيد و حالت سريعتر را انتخاب كنيد . در برخي مواقع اين تغيير ميتواند منجر به افزايش كارايي شود .