QofQ: معالجة البيانات على مستوى التطبيق باستخدام الاستعلام عن الاستعلامات


يعد استعلام الاستعلامات طريقة مهمة لإعادة معالجة نتائج الاستعلام على مستوى التطبيق
QofQ هي الطريقة التي يجب عليك استخدامها إذا كنت في مشكلة مع كمية البيانات و / أو عدد الاستعلامات التي لديك أثناء عملية التطوير

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


قبل البدء

إذا كنت ستستخدم طريقة الاستعلام عن الاستعلامات ، فتأكد من حصولك على البيانات الوحيدة في الاستعلام الرئيسي التي ستستخدمها في الاستعلامات الأخرى. لأن الاستعلام عن الاستعلامات لا يدعم inner or outer join!على الرغم من أنه يدعم جميع المفاهيم الأخرى ، إلا أنه لن يكون من الممكن استخدام أكثر من استعلام واحد معًا. يسمح فقط بدمج استعلامات متعددة تنتمي إلى نفس المجموعة مع مفهوم الاتحاد ، مع قاعدة إضافة واحدة تحت الأخرى.

خطة B

بدأنا العمل على الفور وكتبنا استعلامنا، ولهذا السبب نريد إنشاء الإجماليات من خلال التجميع في مكان ما. على سبيل المثال ، المجاميع الفرعية وفقًا لمعدلات ضريبة القيمة المضافة. في أفضل حالة ، من الممكن إنشاء استعلام جديد وتشغيله في قاعدة البيانات. لكن ألا نملك هذه البيانات بالفعل؟ بعد ذلك ، قد تجد أنك قمت بتكرار الرمز عندما تفكر في كيفية حساب البيانات التي لدينا ومحاولة تقليل عمليات قاعدة البيانات عن طريق إنشاء مصفوفات ومتغيرات في منتصف عملية الحلقة. بالطبع ، إذا كنت قد انتهيت من المواقف الواردة في المقالة بعنوان "DevLog - تصفية وتعيين وتقليل العمليات"، يمكنني القول أنه مقبول ، لكن بخلاف ذلك لا يمكنني القول مطلقًا. في أحسن الأحوال ، لدينا مجموعة سجلات ، أي نتيجة الاستعلام ، وإذا اعتقدنا أنه إذا قمنا بالفعل بتشغيل هذا الاستعلام مرة أخرى ، فيمكننا القيام بعملنا ، فنحن في المكان المناسب. خطتنا ب جاهزة!

يقوم استعلامنا ببساطة باسترداد السجلات من قاعدة البيانات في الجدول tbl_bill_satirlar بعد 10.10.2010. لا تقل أنه لا يوجد مثل هذا الاستعلام ، دعنا نفترض أنه يوجد. نخرج هذا إلى جدول مع عملية الحلقة. كل شيء على ما يرام حتى الآن ، ماذا عن إجمالي العمليات؟ المجاميع الكلية أكثر وضوحًا. كما لو أن استعلامًا كهذا سيفي بالغرض

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

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

إذا كان المطلوب أكثر

في بعض الأحيان قد نحتاج إلى المزيد. بالنسبة لهذه العمليات ، نحتاج إلى القيام بالعمليات التي تشكل أساس مفهوم No-Sql المسمى Pipe. باستخدام استعلام استعلام الاستعلامات ،يمكن استخدام عملية Pipe في هذه المرحلة ،عن طريق الجمع بين المجموعات الفرعية التى تم أنشاءهلا أعرف أي من هذه العمليات تريد. كما ذكرت سابقا ، يمكنك فهمها بشكل أفضل إذا قرأت المقالة التي ذكرتها مع "DevLog - تصفية وخريطة وتقليل العمليات". ستحتاج إلى استخدام المفاهيم الواردة في هذه المقالة لاستخدام النتيجة الخاصة بك عن طريق إنشاء أنابيب وإنشاء مجموعات فرعية أو هياكل لبياناتك.

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

بهذه الطريقة ، أثناء عملية الحلقة ، نقوم بتصفية الصفوف التي تنتمي إلى الفاتورة ذات الصلة من الاستعلام query_invoice_satirlar والحصول عليها كمجموعة فرعية دون إنشاء صلة. سيعمل هذا بشكل أفضل من استعلام قاعدة البيانات الكلاسيكي. إذا أردنا القيام بعملية Pipe

في هذا المثال ، يتم دمج عنوان الفاتورة مع سطر المجموعة الفرعية وتعبئته في مصفوفة. إذا كان متغير الفاتورة في المصفوفة عبارة عن مجموعة فرعية من بنية صف الفاتورة ، فسيحتوي على الاستعلام الخاص بهذه الفاتورة. كما أنه يجعل من الممكن عمل القيمة المعادة داخل عملية الحلقة دون تنفيذ العملية. هنا ، باستخدام valueArray ، أخذنا مصفوفة من معرفات الفواتير وأعطينا قيمة معرف الفاتورة للاستعلام عبر العنصر مع عملية الخريطة ، وقيمة الفهرس لوظيفة queryGetRow للحصول على صف الفاتورة. على الرغم من أننا لم ننفذ العملية بمنطق no-sql بالضبط ، فقد أجرينا العملية جزئيًا بتنسيق no-sql وجزئيًا بتنسيق sql. من الممكن إجراء نفس العملية بتنسيق no-sql باستخدام الطرق الواردة في المقالة المسماة "DevLog - تصفية وتعيين وتقليل العمليات".

سيكون من الممكن أيضًا استخدام هذه العملية كمجموعات فرعية في أكثر من مجموعة فرعية و / أو على أكثر من عمق. ومع ذلك ، من المفيد معرفة الوظائف التالية لهذه العمليات

مصفوفة  valueArray (استعلام ، اسم العمود)

إرجاع القيم الموجودة في العمود المحدد في استعلام كمصفوفة. يجب تحديد اسم الاستعلام (كمتغير) واسم العمود (كسلسلة).queryGetRow(query, row_index) struct

queryGetRow (استعلام ، row_index) هيكل

إرجاع الصف المحدد في استعلام كقيمة مفتاح في البنية. المفتاح هو اسم العمود وتحتوي القيمة على قيمة العمود

الوظيفتان المذكورتان أعلاه مطلوبتان للتبديل من قاعدة SQL إلى قاعدة no-sql. ومع ذلك ، يمكنك أيضًا استخدام عمليات queryMap, queryFilter, queryReduce بالبقاء في طبقة sql. ومع ذلك ، فإن أهم نقطة يجب تذكرها هي أن البقاء في sql (إجراء عمليات مباشرة على الاستعلام ، بما في ذلك qoq) سيحد من مرونتك أو يتسبب في بذل الكثير من الجهد لاكتساب المرونة. نظرًا لأن البيانات الموجودة في الاستعلامات هي بيانات أولية ، فإن إضافة أعمدة جديدة ليس بالأمر السهل. ومع ذلك ، نظرًا لأن نهج no-sql سيجعلك تستخدم البنيات والمصفوفات ، فإنه يسمح لك باستخدام أنواع مختلفة من الأعمدة والبيانات في كل عملية.

النهج الصحيح

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

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


?

?