क्या आप किसी औद्योगिक अनुप्रयोग की SQL क्वेरी जनसंख्या (उदाहरण के लिए, अनुकूलन के लिए) के वन विश्लेषण से मिले हैं?

मैं यह सवाल खाबरोवस्क नागरिकों से पूछना चाहता हूं।

आधुनिक सूचना प्रणाली विभिन्न प्रकार के डीबीएमएस पर निर्मित हैं और फिर भी संबंधपरक डीबीएमएस सबसे आम और उपयोग किए जाते हैं । इस विषय पर दिलचस्प आँकड़े यहाँ और यहाँ ।


सिस्टम के विकास और संशोधन के दौरान, विश्लेषकों और डेवलपर्स के ज्ञान के औपचारिककरण का स्तर कम रहता है (स्मार्ट क्वेरी बनाने या कई स्पष्ट नियमों को ध्यान में रखने का स्वचालन) और अक्सर परिणामी एसक्यूएल प्रश्नों को "सामान्य रूप से", "हमेशा की तरह", "वे हमारी कंपनी में लिखते हैं"। और अनुकूलन मुद्दे DBMS में क्वेरी निष्पादन के चरण और अनुकूलन के बाद के चरणों में रहते हैं (सबसे खराब स्थिति में, जब सब कुछ धीमा होने लगता है तो वे प्रतीक्षा करते हैं)।

मैनुअल कोड की मात्रा भले ही बड़ी हो अपने मैनुअल लेखन (ओआरएम सहित) से बचने के लिए बड़ी संख्या में सुविधाजनक उपकरण की उपस्थिति। और ऐसे उपकरणों का उपयोग करना हमेशा संभव नहीं होता है, खासकर जब जटिल डेटा विश्लेषण सहित बहुत जटिल विश्लेषणात्मक प्रश्नों की बात आती है। और ओआरएम जैसे उपकरण कम या ज्यादा हालिया परियोजनाओं में उपयोग किए जाते हैं, और केवल तुच्छ प्रश्नों के लिए।

किसी भी मामले में, प्रश्नों को अनुकूलित करने की आवश्यकता है और संभवतः, औद्योगिक आधार पर DBMS की संरचना स्थिर है । यहां तक ​​कि "सही" डिजाइन के बाद से इसे टाला नहीं जा सकता है वातावरण बदल रहा है और ग्राहक को हमेशा यह नहीं पता होता है कि कल क्या होगा (कानून, बाजार, ग्राहक, नए विचार कैसे दिखाई देंगे, आदि)।


DBMS में अनुकूलन करते समय, एक ही समस्या की कई समस्याएं उत्पन्न होती हैं , जब एक नियमित प्रोग्रामिंग भाषा के लिए कोड का अनुकूलन - एक ही कोड की खोज और ट्रैकिंग, नए, अनुकूलित, आदि के साथ सभी जगहों पर प्रतिस्थापित करना ... और यह अच्छा होगा यदि सभी SQL प्रश्न एक ही में थे एक जगह और यह एक सरल खोज के माध्यम से जाना और इसे बदलना संभव होगा))) लेकिन यह ऐतिहासिक रूप से ऐसा हुआ है कि अधिकांश प्रौद्योगिकियां क्वेरी परत को अलग-अलग संरचनाओं / वस्तुओं / फाइलों / आदि में अलग नहीं करती हैं। सर्वोत्तम स्थिति में, अनुरोध वास्तव में अलग-अलग फ़ाइलों में आवंटित किए जाते हैं।

सभी प्रश्नों को प्राप्त करने का एक विकल्प हो सकता है, उदाहरण के लिए, एक SQL लकड़हारा (लगभग सभी DBMS में एक अंतर्निहित या खराब हो सकता है)। लेकिन इस मामले में, आपको सभी अनुरोधों को प्राप्त करने के लिए अवधि चुनने की आवश्यकता है, उदाहरण के लिए, एक वर्ष में, जिसमें एक लंबा समय लगता है (एक नियमित उद्यम के लिए, सभी बुनियादी संचालन जो हो सकते हैं ... लगभग :) एक वर्ष में होते हैं), और मापदंडों का निर्धारण करने की समस्या खुली रहेगी ...

यहाँ, हैबे पर, और रूसी में इंटरनेट पर। और अंग्रेजी। भाषाओं में क्वेरी ऑप्टिमाइज़ेशन और DBMS संरचना के बारे में अलग-अलग जानकारी होती है, लेकिन बाद के अनुकूलन के लिए सभी प्रश्नों का विश्लेषण करने के विषय पर वास्तव में पर्याप्त सामग्री नहीं होती है। और इसके लिए विश्लेषणात्मक, स्वचालित उपकरणों की अधिक सिफारिशों के लिए, मुझे नहीं मिला ...

मुझे बताओ, खाबरोवस्क निवासियों, क्या आपने आवेदन एसक्यूएल प्रश्नों की पूरी आबादी के व्यापक विश्लेषण के साथ मुलाकात की है?

मेरी राय में, एसक्यूएल प्रश्नों की संरचना के व्यापक विश्लेषण के तीन मुख्य कारण हैं :
1. कोड अनुकूलन : डुप्लिकेट कोड को हाइलाइट करना, इसके अनुकूलन के दौरान डुप्लिकेट कोड को बदलना, कोड संरचना में सुधार के लिए विभिन्न स्वचालित युक्तियां जारी करना।
2. कोड रीफैक्टरिंग (इस मामले में अनुकूलन एक अनिवार्य प्रभाव नहीं है)।
3. वैज्ञानिक रुचि , उदाहरण के लिए, बाद के अनुसंधान के लिए औद्योगिक प्रणालियों के एसक्यूएल जंगलों का विश्लेषण, उदाहरण के लिए, डीबीएमएस के संचालन के अनुकूलन के लिए नए एल्गोरिदम का विश्लेषण करने के लिए एसक्यूएल क्वेरी वन का अनुकरण।

मेरी राय में, इस तरह के विश्लेषण की उपलब्धता डीबीएमएस में अनुकूलन एल्गोरिदम पर काम करने वाले कई प्रोग्रामर और कुछ वैज्ञानिकों के काम को काफी आसान बनाएगी।