فروم تخصصی - پشتیبانی CPSD

نسخه‌ی کامل: چگونه یک دیتابیس کارآمد داشته باشیم
شما در حال مشاهده‌ی نسخه‌ی متنی این صفحه می‌باشید. مشاهده‌ی نسخه‌ی کامل با قالب بندی مناسب.
سلام

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

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

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

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

غير فعال كردن AutoCorrect

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

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

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 ) ، تحمل گذر اين زمان براي او ساده تر بوده و در واقع برنامه از ديد او ، درخواستش را سريعتر به انجام ميرساند !

موفق باشید
مناسب است گريزي نیز به مساله اي نه چندان بي ارتباط به موضوع فعلي داشته باشیم .

يك سوء تعبير در خصوص مبحث بهينه سازي و سرعت اجرا وجود دارد .

عمليات بهينه سازي در دو بخش مورد بحث و بررسی قرار میگیرد :

- كاهش نياز به منابع سيستمي ( به تبع آن كاهش سربار كاري )

- افزايش سرعت اجرا

عمليات بهينه سازي و يا همان Optimization يكي از موارديست كه زیاد مورد توجه واقع نشده .

اندازه گيري ميزان بهينه سازي صورت گرفته , توسط روشهايي خاص به انجام ميرسد و فراتر از مشاهده روال اجرايي برنامه میباشد ، آن هم از طريق رصد چشمي .

سوء تعبيري كه عموماً به انجام میرسد این است كه تفاوت اجرا , در هنگام اولين اجراي برنامه و دفعات اجراي بعدي تابعي از بسیاری متغيرهاست كه از آن جمله میتوان به : ميزان حافظه سيستم ، سرعت هارد ديسك ، سرعت شبكه و پارامترهايي ديگر اشاره كرد كه عموماً در هنگام اجرا دچار تغيير میشوند و نتايج اندازه گيري برون پروسه اي را دچار خطای کاذب ميكنند . ( معمولاً افزایش بهینه سازی کاذبی را تداعی میکنند )

سنجش ميزان بهينه سازي ها ، برآيندي از ميزان افزايش بهره وري زير سيستمهاي موجود میباشد

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

به طور مثال کاهش تعداد خطوط برنامه نویسی و یا استفاده از برخی دستورات معادل به فراخور الگوریتم مورد استفاده میتواند جهش قابل توجهی را در سرعت اجرای عملیات مورد نظر به نمایش بگذارد .

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

تا مبحثی دیگر و با امید موفقيتی روز افزون شما