नोट
इस पेज तक पहुँच के लिए प्रमाणन की आवश्यकता होती है. आप साइन इन करने या निर्देशिकाओं को बदलने का प्रयास कर सकते हैं.
इस पेज तक पहुँच के लिए प्रमाणन की आवश्यकता होती है. आप निर्देशिकाओं को बदलने का प्रयास कर सकते हैं.
सबसे सरल और तेज़ डेटा क्वेरी पैटर्न है:
- एक एकल तालिका या दृश्य
- सर्वर पर प्रीफ़िल्टर्ड आपको क्या चाहिए
- कॉलम अपेक्षित क्वेरीज़ के लिए सही रूप से अनुक्रमित किए गए हैं
जब आप अपना ऐप्लिकेशन डिज़ाइन करते हैं, तो आपको यह सोचना होगा कि डेटा को तेज़ी से कैसे क्वेरी करें. डेटा को क्वेरी करने का सबसे अच्छा तरीका एक एकल तालिका या दृश्य का उपयोग करना है जिसमें आपकी आवश्यक सभी जानकारी है, और इसे अपने ऐप में प्रदर्शित करने से पहले सर्वर पर फ़िल्टर करें। आपको यह भी सुनिश्चित करने की आवश्यकता है कि डेटा को फ़िल्टर करने या सॉर्ट करने के लिए आपके द्वारा उपयोग किए जाने वाले कॉलम ठीक से अनुक्रमित हैं। यह आपके ऐप को तेज़ और स्मूथ बनाता है।
उदाहरण के लिए, मान लीजिए कि आपके पास एक गैलरी है जो ग्राहकों और उनके विक्रेताओं की सूची दिखाती है। यदि आप ग्राहक और विक्रेता की जानकारी को अलग-अलग तालिकाओं में संग्रहीत करते हैं, तो आपको प्रत्येक ग्राहक के लिए विक्रेता का नाम प्राप्त करने के लिए लुकअप का उपयोग करने की आवश्यकता है। यह आपके ऐप को धीमा कर देता है क्योंकि इसे दूसरी तालिका पर कई प्रश्नों को चलाने की आवश्यकता होती है। एक बेहतर तरीका एक ऐसा दृश्य बनाना है जो ग्राहक और विक्रेता जानकारी को एक तालिका में संयोजित करता है, और उस दृश्य को अपनी गैलरी के लिए डेटा स्रोत के रूप में उपयोग करता है. फिर आपके ऐप को आवश्यक सभी डेटा प्राप्त करने के लिए केवल एक क्वेरी चलाने की आवश्यकता होती है।
क्वेरी गति और डेटा सामान्यीकरण के बीच एक समझौता है। डेटा सामान्यीकरण का मतलब है कि आप डेटा को केवल एक बार संग्रहीत करते हैं, और दोहराव से बचते हैं। यह डेटा को सुसंगत और सटीक रखने में मदद करता है। हालाँकि, कभी-कभी आपको प्रश्नों को तेज़ और आसान बनाने के लिए कुछ डेटा की नकल करने की आवश्यकता होती है। आपको अपने ऐप डिज़ाइन और तालिका संरचना में इन दो लक्ष्यों को संतुलित करने की आवश्यकता है। अन्यथा आपका ऐप धीमा और धीमा हो जाएगा क्योंकि इसे विभिन्न तालिकाओं से डेटा को फ़िल्टर करने और जोड़ने के लिए कई काम करने की आवश्यकता होती है।
सर्वर-साइड दृश्यों का उपयोग करें
इन लक्ष्यों को संतुलित करने में मदद करने के लिए दृश्य शायद सबसे आम उपकरण हैं। वे प्रश्नों के लिए एक एकल तालिका संरचना प्रस्तुत करते हैं, क्वेरी में आपको जो चाहिए उसके लिए डेटा को प्रीफ़िल्टर करते हैं, और लुकअप और अन्य तालिकाओं में शामिल होने को सक्षम करते हैं। फ़िल्टर के लिए, लुकअप और दृश्य के लिए जोड़ने सर्वर पर गणना की जाती है, क्योंकि पेलोड और क्लाइंट-साइड गणना दोनों को कम से कम किया जाता है।
गैलरी पर बहुत अधिक लुकअप से बचें
कोई गैलरी किसी डेटा स्रोत से कई रिकॉर्ड प्रदर्शित कर सकती है. लेकिन कभी-कभी, आपको किसी अन्य डेटा स्रोत से अतिरिक्त जानकारी दिखाने की आवश्यकता होती है जो मूल स्रोत से संबंधित होती है। उदाहरण के लिए, आपके पास एक गैलरी है जो ग्राहकों की सूची दिखाती है, और आप उस विक्रेता का नाम दिखाना चाहते हैं जिसे प्रत्येक ग्राहक को असाइन किया गया है। विक्रेता का नाम ग्राहक की जानकारी से भिन्न डेटा स्रोत में संग्रहीत किया जाता है. विक्रेता का नाम दिखाने के लिए, आपको एक लुकअप फ़ंक्शन का उपयोग करने की आवश्यकता है जो अन्य डेटा स्रोत में मेल खाने वाले रिकॉर्ड को ढूंढता है। यह लुकअप मानों के साथ मूल तालिका का विस्तार करता है।
हालाँकि, यदि आपके पास कई रिकॉर्ड और कई लुकअप हैं तो तालिका का विस्तार करना बहुत धीमा हो सकता है। गैलरी में प्रत्येक रिकॉर्ड के लिए, ऐप को अन्य डेटा स्रोत के लिए एक अलग क्वेरी चलाने और लुकअप मान प्राप्त करने की आवश्यकता होती है। इसका मतलब यह है कि ऐप को प्रत्येक रिकॉर्ड के लिए कई प्रश्न चलाने की आवश्यकता हो सकती है, जिसमें लंबा समय लग सकता है और ऐप के प्रदर्शन पर असर पड़ सकता है। इस एंटी-पैटर्न को कभी-कभी "N वर्ग, (n^2)" या "N+1" समस्या के रूप में जाना जाता है।
Startswith या फ़िल्टर का उपयोग करें
Power Fx डेटा खोजने के कई तरीके प्रदान करता है. सामान्य तौर पर, एक ऐसे व्यंजक का उपयोग करें जो एक सूचकांक का लाभ उठाता है जैसे कि StartsWith या फ़िल्टर एक के बजाय जो पूरी तालिका को पढ़ता है जैसे in. इन ऑपरेटर इन-मेमोरी संग्रह के लिए ठीक है या यदि बाहरी डेटा स्रोत तालिका बहुत छोटी है।
डेटा डुप्लिकेट करने पर विचार करें
कभी-कभी डेटा किसी क्वेरी में एक्सेस करने में धीमा होता है क्योंकि यह किसी भिन्न स्थान या स्वरूप में संग्रहीत होता है. क्वेरी को तेज़ बनाने के लिए, आप धीमे डेटा की प्रतिलिपि बना सकते हैं और इसे स्थानीय रूप से एक तालिका में संग्रहीत कर सकते हैं जो तेज़ और क्वेरी करने में आसान है। हालाँकि, इसका मतलब यह है कि स्थानीय डेटा मूल डेटा का सबसे अद्यतन संस्करण नहीं हो सकता है। फिर स्थानीय डेटा को समय-समय पर अपडेट करने के लिए एक और प्रक्रिया चलाएँ। यह प्रक्रिया एक Power Automate प्रवाह, एक प्लगइन, एक संग्रहीत प्रक्रिया, या कोई अन्य विधि हो सकती है जो डेटा को एक स्थान से दूसरे स्थान पर ले जा सकती है।
स्थानीय डेटा को अपडेट करने की आवृत्ति आवश्यकता आपकी व्यावसायिक आवश्यकताओं पर निर्भर करती है। आपके ऐप्लिकेशन के लिए डेटा कितना ताज़ा होना चाहिए? उदाहरण के लिए, मान लीजिए कि आप Contoso के लिए काम करते हैं, जो एक ऐसी कंपनी है जो साइकिल बेचती है. उपलब्ध साइकिलों की सूची एक उत्पाद डेटाबेस में संग्रहीत की जाती है जिसे आप एक कस्टम कनेक्टर में एपीआई के माध्यम से एक्सेस कर सकते हैं। लेकिन कहें कि एपीआई कॉल धीमी है, और इसलिए आप उत्पाद डेटा को कॉपी करने और इसे स्थानीय रूप से एक तालिका में संग्रहीत करने का निर्णय लेते हैं। फिर आप एक ऐसा दृश्य बनाते हैं जो आपकी तालिका को आपके अनुप्रयोग के लिए अन्य प्रासंगिक डेटा के साथ जोड़ता है. आप एक Power Automate प्रवाह भी बनाते हैं जो हर दिन चलता है और API से नवीनतम उत्पाद डेटा के साथ आपकी तालिका को अद्यतन करता है. फिर आपका ऐप्लिकेशन स्थानीय डेटा को तेज़ी से क्वेरी कर सकता है और डेटा ज़्यादा से ज़्यादा एक दिन पुराना होता है.
अच्छा प्रदर्शन सुनिश्चित करने के लिए एंटरप्राइज़-ग्रेड अनुप्रयोगों में डेटा की नकल करना एक सामान्य प्रकार की तकनीक है। आप डेटा को एक एकल तालिका में डुप्लिकेट करने के लिए Dataverse प्लगइन्स, संग्रहीत प्रक्रियाओं या डेटा मूवमेंट का उपयोग कर सकते हैं जो क्वेरी करने के लिए अनुकूलित है। मुख्य प्रश्न यह है: यह डेटा कितना अद्यतित होना चाहिए? यदि आप कुछ देरी कर सकते हैं, तो आप अपने ऐप को गति देने के लिए इस तकनीक का उपयोग कर सकते हैं।
सुझाव
इस लक्ष्य को प्राप्त करने के लिए, निम्नलिखित प्रश्नों और सुझावों पर विचार करें:
- किसी ग्राहक के लिए गैलरी या डेटा ग्रिड में डेटा मान देखना कितना महत्वपूर्ण है? क्या पहले किसी रिकॉर्ड का चयन करना और फिर डेटा को किसी प्रपत्र में दिखाना स्वीकार्य होगा?
- क्या कोई दृश्य डेटा को सही प्रारूप में देखने के लिए आवश्यक पूर्व-कार्य कर सकता है?
- क्या आप एक "IN" ऑपरेटर का उपयोग कर रहे हैं जहां "StartsWith" काम करेगा?
- आपका डेटा कितना वर्तमान होना चाहिए? क्या कोई डेटा दोहराव रणनीति है जिसका उपयोग आप डिफ़ॉल्ट रूप से अपनी क्वेरी को एक ही तालिका पर काम करने के लिए कर सकते हैं?