هل يمكن تسريع تقرير لاستعلام جدولي !

نعم ، بأن تجعل الحقول المستعلم عنها ( مفهرسة Index ) و بأن تتجنب التعقيد في الاستعلام ( أحياناً أضطر لإعادة بناء البرنامج إذا اقتضت الضرورة ، و هي محل نقاش عنيف بيني وبين بعض المبرمجين ) و تذكر أن الأدوات ( الهاردوير ) لها تأثير خطير أيضاً

من خلال تجربة متواضعة أوافق الأخ صالح بأن تعقيد كود الاستعلام خاصة المكتوب في محرر فيجوال بيسك يحد من سرعة التنفيذ, و عندما قمت بالتعديل و ركزت على الاستعلام بواسطة الجداول كانت النتيجة مذهلة, و تخلصت من مشكلة أرهقتني و هي تعليق الأكسس عند تنفيذ الاستعلام, و المسألة مفتوحة للنقاش فالكثير من الأمور يمكن أن تحد من سرعة البرنامج و أهمها ما أشار اليه الأخ صالح في عدة مشاركات و المتعلقة بتعقب التصحيح التلقائي التي تكون مفعلة فهي تسبب مشاكل كبيرة للبرنامج, اضافة الى العديد من الأمور التي لها دور في تحديد سرعة البرنامج.

أضم صوتي لصوت الأستاذ Biskra هذه القضية مهمة للغاية و يجب أن تأخذ حقها من النقاش.

و قد أثلج صدري عندما قرأت له في أحد مشاركاته نقداً مبطناً يتعلق بهذا الموضوع فقلت في نفسي حسناً النقاش معه لن يسبب صداعاً لأي منا فهو يحمل نفس الرأي تقريباً.

الجدل الذي يدور بيني و بين أغلب المبرمجين هو تمسكهم الأعمى بنظريات بناء قواعد البيانات و ما يتبعها من مناهج تطوير البرامج ، بعض هذه النظريات تصلح للكلام عنها فقط و لكن أداءها عمليا أعتبره مأساة ، مثل نظرية عدم تخزين الحقول الحسابية و أن يتم الحساب لحظة الحاجة للمعاينة فقط و المبرر هو عدم تضخيم حجم قاعدة البيانات و تعبئتها ببيانات ميتة ، كلام جميل للغاية و لكن ضع تحته ألف خط أحمر فمن وجهة نظري أن هذا المبرر لا يكفي و يمكن تحقيق هدف المحافظة على حجم قواعد البيانات بأساليب أخرى لا تؤثر على مستوى أداء البرنامج .

من ناحية أخرى، ليس مطلوباً مني أن أتخيل فهذه واقعة عملية مثل الاستعلام الذي تحدث عنه الأخ رامي ينتج عنه 400000 ألف سجل ، و لكن تخيل لو أن هذه السجلات حسابية و النواتج غير مخزنة أصلاَ ، البرنامج سواءً كان أكسس أو غيره عليه أن يقوم ب 400000 ألف عملية حسابية ، ماذا لو كانت العملية الحسابية معقدة في حد ذاتها ؟! ماذا لو كانت العملية تتطلب الحصول على معلومات من جداول مختلفة ؟؟! ماذا لو كان من الواجب القيام بعمليات حسابية تمهيدية للمعلومات المطلوبة من تلك الجداول ؟؟؟؟؟؟؟؟؟؟؟!!!!!!!!!!!!!!!؟؟؟؟؟؟؟؟؟

و من ناحية أخرى أيضاَ ، و هي إستراتيجية طلب المعلومة ، فمثلاً في حالة الأخ رامي أليس من الظلم أن يطلب منه تقرير ينتج عنه هذا العدد من السجلات ، و هو عدد قابل للزيادة، إذا أراد صاحب القرار أن يمنح ثانية واحدة فقط للاطلاع على كل سجل فسيحتاج إلى 14 يوم عمل تقريباً لينتهي منها ، و نحن لم نتحدث عن تحليلها أو تدقيقها أو...أو.... إذاً ؟؟؟؟؟

أنا أعتقد أن مسألة عدم تخزين البيانات الحسابية نظرية غير مطلقة و يجب أن تخضع لدراسة الحالة ، فأنا أؤيدها فقط في الحسابات التي تعتمد على تواريخ قابلة للتحديث ، كأن تحسب مدة عمل الموظف من تاريخ بدء عمله حتى هذه اللحظة تمهيداً لحساب مستحقاته عند نهاية خدمته أو لحساب أمر آخر ، هذا منطقي و صحيح و لكن لا أحد يستطيع إقناعي أنه لا يجب أن أحفظ النتيجة النهائية في مكان ما عندما يتم خروج الموظف ، و أنه عليّ أن أقوم بنفس العملية كلما أردت القيام بحسابات أخرى تكون هذه العملية جزءاً منها ، لماذا أكرر العملية طالما أنها حفظت في مكان ما ، فلأحصل على المعلومة من مكانها فقط و كفى .!! و تكلفة حفظ مثل هذه المعلومة يمكن حساب مقدارها في قاعدة البيانات ، و لكن كيف تحسب حجم الضرر الذي سيقع على أداء البرنامج إذا تغيب هذا الأسلوب .

فهل هناك من يؤيد عدم تخزين قيمة الفاتورة ( مثلاً ) و يؤيد القيام بتنفيذ المعادلة في كل مرة تتطلب الحصول على قيمتها سواء لحسابها أو للحسابات اليومية أو الشهرية أو الفصلية أو... أو ... إلخ . الفاتورة طبعت و خرجت من الذمة و انتهى أمرها فلماذا تبقى مبهمة في البرنامج . أنظر الفرق في هذا السيناريو للحالتين التي نؤيدها و التي نعارضها .

أدخلت بيانات الفاتورة و قام البرنامج بحساب قيمتها و قيمة الخصم ( إن وجد ) و عرفت الناتج الإجمالي الذي يساوي

( قيمة السلعة أو الخدمة * عدد الوحدات ) – ( الخصم الذي قد يكون حسابياً أيضاَ مثل النسبة المئوية )

مع ملاحظة احتمال أن يكون الخصم خاضعاً لحالات متعددة . المهم أنك في النهاية تجمع المجاميع و تحصل على قيمة الفاتورة أو العقد و انتهى الأمر .

السؤال الآن : أيهما أصح منطقياً و أفضل لأداء البرنامج ، أن أحفظ هذه القيمة في حقل إجمالي الفاتورة ، و استعلم عنها بشكل عادي كلما دعت الحاجة في التقارير و التحاليل ، أم أقوم بتنفيذ المعادلة السابقة على بساطتها كلما دعت الحاجة ، و هل الإجمالي سرّ مطلسم لا يمكن معرفته إلاّ في حينه ؟؟!!

أيهما أبسط، أن أقول للبرنامج أحضر لي ( قيمة الحقل الفلاني )، أم أقول له أحضر لي ( قيم الحقول الفلانية ) ثم اجمع و اطرح و اقسم و اضرب ؟!؟!

هذا في الأحوال و العمليات البسيطة، فكيف هو الحال في عمليات الغوص و التحليل و المقارنة و التقييم و غيرها من العمليات المعقدة فنياً؟؟

وكيف سيكون شكل و منطق الكود الذي يكتبه المبرمج لتنفيذ تلك الأوامر ؟؟ و كيف سيدقق فيه و يصونه ؟؟ و كيف يدخل عليه تعديلات إذا كانت الجمل و الأحداث مترابطة ؟؟

يمكن النظر للموضوع من عدة زوايا أخرى كثيرة، المهم أن نصل في النهاية إلى الحل الأكثر منطقية .

كلام جميل جدا و استفسارات منطقية جدا , فلا يعقل من أجل معلومة لسجل واحد نلزم البرنامج للقيام بـ 40.000 عملية حسابية , المنطق يقتضي أن نجيب بلا دون نقاش.

لكن ما دام النقاش قد فتح, يجب أن نبحث عن الجواب المقنع أو لنقل المنطقي, لنسأل من جديد ما هي المعلومات " نحن نتحدث عن نتائج العمليات الحسابية" التي يمكن تخزينها و ما هي المعلومات التي يحبذ ابقاؤها في مجال الاستعلام للحصول عليها عند الحاجة؟

من خلال شرحك أخي صالح فقد تحدثت عن الموظف المتقاعد أو الذي انتهت خدمته , من هنا يمكنني أن أفكر و أقول أن النتيجة الثابتة يمكن حفظها و الحصول عليها متى شئنا, و بالمقابل نقول أن النتيجة المتغيرة هي التي نبقيها في مجال الحصول عليها بواسطة الاستعلام, لأنها قابلة للتغيير...

هل نبدأ النقاش من هنا ؟ أم هناك مكان آخر للبداية؟

حسناً ، بما أنك طرحت السؤال ، إذاً أنت مقتنع بأن المسألة ليست مطلقة ، و أنها قابلة للنقاش و هذا عين التحرر ، و من هنا نبدأ، مسألة تخزين ناتج العمليات الحسابية ، هل هي مطلقة أم متغيرة حسب الحالة ، فما أرمي إليه هو أن التمسك بتطبيق بعض نظريات إدارة قواعد البيانات و التطبيقات قد يكون صحيحاً في أحوال و قد يكون خاطئاّ في أحوال أخرى .

فهل نلزم أنفسنا بالنظرية أم بالحالة ؟ و هل نلزم أنفسنا بقواعد و أصول التصميم أم بالهدف الذي من أجله تم بناء قاعدة البيانات و بالتالي البرنامج ككل ؟؟

القاعدة ليست مطلقة طبعا و كنت دائما أقول عندما يطرح سؤالا حول تخزين قيمة حسابية أقول بأن الخبراء ينصحون بعدم تخزين قيمة العمليات الحسابية و كثيرا من السائلين يقولون أنهم يعلمون بأن هذه الطريقة غير محببة و لكن يطلبون طريقة حفظ النتيجة في السجل.

لذا فأنا متحرر من هذه الفكرة أساسا, و زادني تدخلك تحررا لما أقنعتني بضرورة بقاء 14 يوما لاستعراض البيانات...

أرجو من العضاء التفاعل مع الموضوع و ابداء الرأي في المسألة, بعض المنتديات تعتبر سرعة التعامل مع البيانات مسألة حاسمة في التصميم, و يقسون حتى الوقت الذي يأخذه فتح نموذج اعتمادا على الكواد.

( الخبراء ينصحون ... ) هذا هو النقد المبطن الذي قصدته .

طبعا ينصحون , لاحظ أحدهم ماذا يقول و هذا ما يجب أخذه بعين الاعتبار لما قلنا أن اللقيمة القابلة للتغيير يجب عدم حفظها:

Calculated fields in a table are a BAD IDEA. Any change of an underlying field in any record will make all of the running sum values incorrect.

Running sums can be calculated as NEEDED in Queries, Forms, Reports .....

أخي رامي أضم رأيي للأخوة الأفاضل وأشرح لك هذه النقطة الهامة جدا وهي ما يجب عليك فعله أولا إذهب الـــــى:

Tools

Options

General

هنا قم بإزالة العلامة من على مربع Track name AutoCorrect info

فليجربها الجميع وسيلاحظها أصحاب الملفات العملاقة وخصوصا بإجراءات الاستعلام المزدوج

شكرا للأخ هيثم على النصيحة و قد تم النصح بها أكثر من مرة حتى للذين يعانون من فقدان التقارير لتنسيقها, و لكن الطريقة التي أشرت اليها يمكن الوصول اليها عن طريق الكود التالي و هي تحل عدة مشاكل و تسرع قاعدة البيانات.

الكود يمكن وضعه مثلا في نموذج الافتتاحية في حدث عند الفتح

Application.SetOption "ShowWindowsInTaskbar", False
Application.SetOption "Log Name AutoCorrect Changes", False
Application.SetOption "Perform Name AutoCorrect", False
Application.SetOption "Track Name AutoCorrect Info", False

جربوه و لاحظوا تأثيره في سرعة فتح النماذج التي تحتوي على حقول كثيرة مثلا.

أحسنت أخي Biskra لقد أردت أن أحيط أخانا علما فقط بالطريقة التقليدية للوصول الى ذلك علما أن أغلب ما قرأته في المنتدى ومن تداخلات الإخوان الكرام بسيط وليس متقدم، وكلي أمل من أصحاب الموقع أن يدرجو منتدى لمبرمجي الأكسيس المحترفين أو المتقدمين حتى لا تلتبس الأمور بين فئات المبتدئين والمتقدمين والمحترفين.

وجزاكم الله كل خير