سلام

بحث Optmization یکی از بخشهایی است که متاسفانه اغلب کاربران به سادگی از کنار آن میگذرند

در دنیایی که بسیاری صنایع تمام تلاش خود را به کار میگیرند تا ثانیه ای بر رقیب خود پیشی بگیرند , نادیده گرفتن این امر تنها میتواند ناشی از عدم شناخت بازار از سوی طراح باشد و بس .

یک واقعیت وجود دارد که بسیاری از نرم افزارها غالباً تغییر در ورژن برنامه را تا حدود زیادی در بخش بهینه سازیها و افزایش کارایی اعمال میکنند تا اضافه نمودن امکانات جدید , به طور مثال در نرم افزار 3ds max یک واقعیت در آن جاریست , به طور تقریبی از نسخه 7 به بعد امکانات ظاهر شده و تنوع آنها در حد و اندازه های جهش در ورژن نبوده و این تغییر نسخه ها بیشتر با رویکردی به بهینه سازی و کارایی صورت گرفته اند . ( امکانات جدیدی وجود نداشت که اضافه شود ! )

در این مقاله به مرور تلاش خواهد شد به برخی نکاتی که جهت افزایش سرعت و کارایی میتوان از آنها بهره برد اشاره شود .

ابن گزينه در واقع به عنوان تنظيمي به جهت ياري رساندن به كاربر در هنگام تغيير نام آبجكتها در نظر گرفته شده ، تا تغييرات در نقاط ديگر نيز به صورت خودكار اعمال گردد . گو اينكه اين گزينه همچنان در بسياري موارد عدم كارايي خود را به نمايش ميگذارد و توصيه ميكنم ، حتي در حين طراحي نيز اقدام به غير فعال نمودن آن نموده و عطايش را به لقاي ژنده اش ببخشيد !

اين گزينه جداي از مفيد و يا غير مفيد بودنش در هنگام تحويل پروژه در حالت غير فعال قرار گيرد .

انجام اين عمليات به صورت دوره اي ، ميتواند به طور كامل موجب بهينه سازي عملكرد بانك اطلاعاتي شود ، فعال بودن اين گزينه موجب تاخير در هنگام بسته شدن بانك اطلاعاتي مي شود .

در واقع گزينه Compact بيشترين كار خود را از طريق كاهش حجم فايل و به تبع آن كاهش زمان دسترسي به فايل موجود بر روي هارد ديسك به انجام ميرساند ، كه اين اختلاف حجم خصوصاً در بانكهاي اطلاعاتي با حجم بالا نمود بيشتري پيدا ميكند .

پديده افزايش حجم , در واقع يك پديده درون ساختاري اكسس است كه با حذف و ضبط اطلاعات و اعمال تغيير در آنها به وقوع مي پيوندد . در اين فرآيند اطلاعاتي زائد به وجود مي آيد و در واقع در اين حالت فايل اكسس دچار افزايش حجمي كاذب ميشود كه الزاماً نه ناشي از ورود اطلاعات بلكه ناشي از پديده ای ذاتی از سوی اکسس ميباشد .

پس از عمليات حذف اطلاعات به همان اندازه افزايش حجم ناشي از افزودن اطلاعات ، از حجم فايل كم نخواهد شد . عمليات Compact ميتواند اين نقیصه را مرتفع نمايد .

توضيح : با ذخيره سازي بانك اطلاعاتي در حالت Encrypt شده ، عملاً فايل قابليت Compact شدن را به صورت ظاهري نخواهد داشت ( كاهش حجمي را ملاحظه نخواهيد كرد )

پي نوشت : به طور كلي الگوريتمهاي فشرده سازي قادر به كاهش حجم فايلهاي رمز نگاري شده نيستند و يا حتي در صورت كاهش ، اين حجم چشمگير نيست .

امید بود اكسس قابليت Repair را نیز به صورت منفرد داشت ، اين گزينه بسيار كاربردي تر و حياتي تر از Compact بوده و مشحص نيست كه چرا مايكروسافت اين دو را از قالب يك عمليات يكپارچه خارج ننموده است .

در واقع اكسس و ساختار آن به گونه اي است كه در حين كار اين احتمال وجود دارد كه دچار خطاهايي درون ساختاري شود كه در گذر زمان و به مرور مشكل ساز شوند ، عمليات Repair ميتواند بسياري از اين مشكلات جزئي را قبل از اينكه به يك مشكل جدي تبديل شوند پوشش دهد .

اين ابزار داخلي ميتواند پيشنهاداتي جهت عملكرد بالاتر بانك اطلاعاتي ارائه نمايد و برخي مشكلات ساختاري را مرتفع كند وليكن در ادامه ذكر يك نكته الزاميست :

در برخي مواقع پيشنهادات ارائه شده از سوي این ابزار , منطبق با فكر و ذهن برنامه نويس نيست ، از اين رو تمامي توصيه هاي اين ابزار را به عنوان يك راه حل قطعي فرض ننماييد ، خصوصاً در بخش ارتباطات بين جدولي بايد به پيشنهادات ارائه شده از سوي اكسس با دقت بيشتري عمل نماييد .

در مواقعی برنامه نويس به دلايلي خاص نياز ندارد كه بين برخي جداول ارتباطاتي منطقي را برقرار نمايد ، وليكن اكسس اين امر را ناديده نمي گيرد ، و آن را در ليست پيشنهادي خود لحاظ خواهد كرد .

بهبود عملكرد جداول به خودي خود منجر به افزايش عملكرد پرس و جوها نيز خواهد شد .

در ديگر بخشها و آبجكتها ، خوشبختانه اين ابزار ميتواند پيشنهاداتي مثمر ثمر را ارائه كند .

در برخي مواقع حتي اين امكان ميتواند منجر به بازساري نسبي يك فايل معيوب نيز گردد .

در حين فرآيند طراحي به صورت چندين باره از اين امكان استفاده نماييد و تا حد امكان به توصيه هاي آن عمل كنيد .

در واقع اين اصلاح به بانكهايي اطلاق ميشود كه در آن , اطلاعات ( جداول – Back End ) از ديگر آبجكتها جدا بوده و مابقي آبجكتها در فايلي ديگر نگهداري ميشوند ( پرس و جوها ، فرمها و ... – Front End )

طراحي بانك اطلاعاتي بدين روش منجر به كاهش ذاتي بخشي از كارايي خواهد شد ، كه با اتكا به توصيه هاي موجود ميتوانيد بخش اعظمي از اين كاهش كارايي ( سرعت ) را پوشش دهيد . امتيازاتي در اين فرآيند به دست خواهيد آورد ، به گونه اي كه وزنه اين نوع سبك طراحي را سنگين خواهد نمود .

طراحي بانك اطلاعاتي بدين روش منجر به :

افزايش ايمني اطلاعات

بهبود بسيار زياد در فرآيند ارتقاء نرم افزار

و پيروي از قواعد استاندارد تر طراحي در محيطهاي چند كاربره خواهد شد

استفاده از اين روش در الگوهاي كاري Client/Server الزاميست و در واقع اكسس انتخابي ديگر را در اختيار شما نخواهد گذاشت

نكته قابل ذكر جهت اولين قدم در مرتفع نمودن مشكلات ذاتي اين روش اين است كه تنها اقدام به Link نمودن جداولي در داخل Front End نماييد كه به صورت مشترك بين كاربران مورد استفاده قرار ميگيرند . جداولي كه حاوي اطلاعاتي منحصر به يك كاربر ميباشند را در بخش Front End قرار دهيد

گاهاً جداولي ميان كاربردي طراحي ميشوند كه نقش آنها تنها نگهداري موقتي اطلاعات در طي انجام يك پروسه ميباشد ، اين جداول تا حد امكان در سوي Front End قرار گيرند . ( به طور مثال ممكن است اطلاعاتي خاص به جدولي موقتي Append شوند وپس از اتمام عمليات اطلاعات جدول نيز حذف شود )

اين نكته بيشتر نقش يك ترفند رواني را خواهد داشت تا يك بهينه سازي واقعي و برگرفته از مسائل روانشناسي است تا برنامه نويسي .

مغر انسان به گونه اي است كه هنگامي كه از پايان يك عمليات به طور تقريبي مطلع بوده و ميزان عمليات انجام شده را نيز مشاهده كند ، بسيار منطقي تر ! عمل نموده و آستانه تحملش بالاتر خواهد رفت ( به طور مثال به ايده وجود تايمر در كنار چراغهاي راهنمايي توجه كنيد ، زمان ، تغييري با حالتي كه تايمر وجود نداشته ، نكرده است وليكن گذر زمان آسان تر شده است )

بسياري طراحان اقدام به مخفي نمودن بخش Status Bar مي نمايند ، Progress Bar در واقع در داخل اين بخش گنجانده شده است ، Progress Bar در بسياري عمليات به نمايش در مي آيد ( همچون اجراي يك پرس و جو و ... )

كاربر هنگامي كه بازخوردی از سوي برنامه ، مبني بر اجراي دستور مورد نظرش داشته باشد ( نمایش Progress Bar ) ، تحمل گذر اين زمان براي او ساده تر بوده و در واقع برنامه از ديد او ، درخواستش را سريعتر به انجام ميرساند !

موفق باشید