👩‍👧 👨🏽‍🏫 👩‍❤️‍👨 वेबसाइट वास्तुकला पर सूक्ष्म विचार 🚣🏽 👰🏻 🎖️

हम अपने WIT-e में हैं, बेशक, amblers। खुद की ईआरपी-प्रणाली (इसके बारे में यहां लिखा है - हम 1 सी के बिना कैसे कर सकते हैं? ), इसका स्वयं का सीआरएम-सिस्टम, वितरकों के साथ संचार के लिए अपना स्वयं का एम 2 एम ("अन्य चतुर शब्द और संक्षिप्त रूप जो आप जानते हैं?")। और, ज़ाहिर है, इस 3-पत्र प्रतिमान के ढांचे के भीतर रहने के लिए, डब्ल्यूडब्ल्यूडब्ल्यू के लिए आपका दृष्टिकोण।

यह सब Microsoft के प्यार के साथ शुरू हुआ था, और 90 के दशक के उत्तरार्ध में साइट के कुछ शुरुआती संस्करणों को ASP तकनीक का उपयोग करके बनाया गया था, और इसके तहत एक डेटाबेस के रूप में एक नियमित रूप से MS Access फ़ाइल बिछाई गई थी। वैसे, प्रदाता अभी भी ASP.NET में अपग्रेड होने के 18 साल बाद, ~~अच्छे~~ पुराने ASP पर होस्टिंग की पेशकश करते हैं - यहाँ आपके पास सभी महिमा में विरासत सिस्टम हैं।

सामान्य तौर पर, यह काफी सुविधाजनक है - चूंकि आंतरिक डेटाबेस को एमएस एक्सेस में भी लिखा गया है, साइट के लिए डेटा तैयार करने की प्रक्रिया बहुत सरल थी, एक डेटा प्रारूप से दूसरे में पुन: अनुवाद नहीं होता है (उदाहरण के लिए MySQL)। एक्सेस "" <बाहरी डेटाबेस नाम> "फॉर्म की SQL भाषा के विस्तार का समर्थन करता है, जिसे किसी भी DML निर्देशों के बाद जोड़ा जा सकता है: INSERT, UPDATE, DELETE (यहां अन्य 3-अक्षर का संक्षिप्त नाम)।

जैसे-जैसे यह कड़ी बढ़ती गई, यह बेशर्मी से टूटने लगा (प्लस यह तब स्पष्ट होता है जब mdb-file के साथ डेटाबेस के ताले बंद हो जाते हैं, पूरी साइट को जोर से खटखटाते हैं)। ASP.NET के लिए साइट का अनुवाद मूल रूप से समस्या को हल नहीं करता था, और एक आधार के रूप में एमएस SQL सर्वर पर स्विच करना भी आवश्यक था, लेकिन फिर प्रक्रिया एक अलग दिशा में चली गई। आइए वेबसाइट के प्रदर्शन को थोड़ा अलग दृष्टिकोण से सुधारने की समस्या को देखें।

(वैसे, मेरे 1Gb.ru प्रदाता लिखते हैं कि ASP.NET मानक LAMP बंडल (Linux / Apache / MySQL / PHP) की तुलना में औसतन तेज़ है, जो मेरे लिए एक रहस्योद्घाटन बन गया है। लेकिन मैं यहाँ किस पर भरोसा कर सकता हूँ क्योंकि यह पूरी बात का संचालक नहीं है? )

अस्वीकरण - बाद के विचार प्रतिनिधित्व करते हैं, एक तरफ, कुछ सैद्धांतिक निर्माण निरपेक्षता के लिए उठाए जाते हैं, जिसका अर्थ अक्सर गैरबराबरी को कम करना होता है, दूसरी ओर, ठोस कार्यान्वयन, इसलिए यह नहीं कहा जा सकता है कि लेखक अपनी कल्पनाओं में है और पूरी तरह से अलग है वास्तविकता।

प्रश्न 1. साइट के नीचे एक डेटाबेस क्यों होना चाहिए?

ठीक है, वास्तव में, आप सभी इन-मेमोरी डेटाबेस की गति की प्रशंसा करते हैं, है ना? इसलिए दूर क्यों जाएं, अपने आप को अपनी वेबसाइट के तहत सही करें। और भी अधिक। प्रारंभिक आरंभ में, साइट स्तर पर उपलब्ध सरणियों में सभी डेटा को एक संपूर्ण के रूप में लोड करें (ASP.NET में अनुप्रयोग ऑब्जेक्ट, PHP में ग्लोबल वेरिएबल्स, इसके बाद हर जगह), और डेटाबेस पर प्रश्न लिखने के बजाय, इन सरणियों के माध्यम से बस लूप करें। कुछ भी प्रारंभिक डेटा लोडिंग के लिए उपयुक्त है - एक ही एमएस एक्सेस डेटाबेस, लेकिन कम से कम पाठ सीएसवी फाइलें! - ऑपरेशन बार-बार किया जाता है और इसके निष्पादन का समय कोई भूमिका नहीं निभाता है।

सवाल हैं, लेकिन उनके पास पहले से ही तैयार उत्तर हैं।

, - , ? – ( , -), — ,
( ) . . – ( ) , ? , – / , – , . . Catalog ( -!) 2 – :

MinIndex MaxIndex. , - ( ) – Parts ID Catalog, – .

ध्यान दें कि इस विचार को आगे भी जारी रखा जा सकता है। उसी तरह से जो डेटा को साइट से साइट के डेटा स्ट्रक्चर के तहत डेटाबेस में स्थानांतरित किया जाता है, एक वेब पेज बनाते समय, डेटा को इसकी संरचना में ही रखने की आवश्यकता होती है - यानी जावास्क्रिप्ट सरणियों में। और कोई AJAX, अतुल्यकालिक, संचार त्रुटि से निपटने, और अधिक। और इसलिए यह हमारी साइट पर सभी प्रकार के कॉन्फ़िगरेशन वाले पृष्ठों पर किया गया था।

वैसे, डेटाबेस फ़ाइलों के विपरीत, वेब सर्वर (और वेब ब्राउज़र भी, आरक्षण के साथ) की स्मृति में सरणियाँ उनके द्विआधारी प्रतिनिधित्व के बराबर आकार पर कब्जा कर लेती हैं, जबकि एक एकल तालिका वाला एक खाली डेटाबेस पहले से ही आकर्षित करता है। कई सैकड़ों किलोबाइट।

प्रश्न 2. मुझे वेब सर्वर पर स्क्रिप्ट का उपयोग करने की आवश्यकता क्यों है?

मैं कई लाइनों में कोड का टुकड़ा लाता हूं, जानबूझकर सरलीकृत किया गया है और प्रोग्रामिंग भाषाओं के चरम पर है - VBA (1 साल को छोड़कर)

        Set IE = CreateObject("InternetExplorer.Application")

        IE.Navigate "wit.ru"
        While IE.ReadyState < READYSTATE_COMPLETE
        Wend

        Set str = IE.Document.DocumentElement
        HTML = str.innerhtml

कोड निम्नलिखित करता है - एक प्रसिद्ध कंपनी के एक बार बहुत लोकप्रिय ब्राउज़र के माध्यम से पेज चलाता है, और सर्वर स्क्रिप्ट को शुद्ध HTML के रूप में काम करने का परिणाम बचाता है। आपने अनुमान लगाया, शायद, आगे क्या पेश किया जाएगा? काफी सही - पुराने 90 के दशक में विशुद्ध रूप से HTML जैसी साइट बनाना काफी संभव है।

(1GB.ru से फिर से: "IIS बहुत तेज़ी से और कुशलता से स्थिर फ़ाइलों के लिए अनुरोध करता है")

उसी समय, आपको
wit.ru/card.aspx?id=23&prodid=1022985 जैसे
स्थैतिक वेब पते में ट्रांसकोडिंग पतों के बारे में चिंता करनी पड़ सकती है। पेज भी एक प्रसिद्ध वेब सर्वर ट्यून-अप तकनीक है, जो मूल रूप से खोज इंजन और वेब अनुकूलन को मूर्ख बनाने के लिए आविष्कार किया गया है।

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

निष्कर्ष

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

वेबसाइट वास्तुकला पर सूक्ष्म विचार

निष्कर्ष

More articles: