DNS युक्ति के अनुसार डोमेन नाम की अधिकतम लंबाई है:
255 * 3 =765 <767 (बस मुश्किल से :-))
हालांकि ध्यान दें कि प्रत्येक घटक केवल 63 वर्ण लंबा हो सकता है।
इसलिए मैं सुझाव दूंगा कि यूआरएल को घटक बिट्स में काट दिया जाए।
शायद यह पर्याप्त होगा:
- प्रोटोकॉल फ्लैग ["http" -> 0 ] (स्टोर "http" को 0 के रूप में, "https" को 1 के रूप में स्टोर करें)
- उपडोमेन ["foo"] (255-63 =192 वर्ण:मैं 2 और घटा सकता हूं क्योंकि न्यूनतम tld 2 वर्ण है)
- डोमेन ["उदाहरण"], ( 63 वर्ण )
- tld ["com"] ("जानकारी" को संभालने के लिए 4 वर्ण tld)
- पथ [ "a/really/long/path" ] (जब तक आप चाहें -एक अलग टेबल में स्टोर करें )
- queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( एक अलग कुंजी/मान तालिका में स्टोर करें )
- पोर्टनंबर / प्रमाणीकरण सामग्री जो शायद ही कभी उपयोग की जाती है, यदि वास्तव में आवश्यक हो तो एक अलग कुंजी तालिका में हो सकती है।
इससे आपको कुछ अच्छे लाभ मिलते हैं:
- सूचकांक केवल url के उन हिस्सों पर होता है जिन पर आपको खोज करने की आवश्यकता होती है (छोटा सूचकांक!)
- प्रश्नों को विभिन्न url भागों तक सीमित किया जा सकता है (उदाहरण के लिए facebook डोमेन में प्रत्येक url ढूंढें)
- कोई भी url जिसका उप डोमेन/डोमेन बहुत लंबा है वह फर्जी है
- क्वेरी पैरामीटर को छोड़ना आसान है।
- आसान करने के लिए केस असंवेदनशील डोमेन नाम/tld खोज
- सिंटैक्स शुगर ("://" प्रोटोकॉल के बाद, "।" को उपडोमेन/डोमेन, डोमेन/टीएलडी के बीच, "/" टीएलडी और पथ के बीच, "?" क्वेरी से पहले, "&" "=" में छोड़ दें क्वेरी)
- प्रमुख विरल तालिका समस्या से बचा जाता है। अधिकांश url में न तो क्वेरी पैरामीटर होंगे, न ही लंबे पथ। यदि ये फ़ील्ड एक अलग तालिका में हैं तो आपकी मुख्य तालिका आकार हिट नहीं करेगी। क्वेरी करते समय अधिक रिकॉर्ड मेमोरी में फिट हो जाएंगे, इसलिए क्वेरी का प्रदर्शन तेज़ होगा।
- (यहां अधिक लाभ)।
