क्या मुझे डीबी में फ्लाई या स्टोर पर एक स्लग बनाना चाहिए?

Question

एक स्लग एक यूआरएल का हिस्सा है जो किसी पृष्ठ का वर्णन या शीर्षक करता है और आमतौर पर एसईओ में सुधार करने वाले पृष्ठ के लिए समृद्ध कीवर्ड होता है। जैसे इस यूआरएल में PHP/JS - Create thumbnails on the fly or store as files कि अंतिम खंड "php-js-create-thumbnail-on-the-fly-or-store-as-files" स्लग है।

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

अब तक मैं हर एक के लिए इन समर्थक अंक लेकर आए हैं:

स्टोर स्लग: - "तेज़" प्रोसेसर हर बार (एक बार उत्पन्न होता है)

उत्पन्न करने के लिए की जरूरत नहीं है जेनरेट-ऑन-द फ्लाई: - लचीला (स्लग एल्गोरिदम समायोजित कर सकते हैं और पूरी तालिका के लिए regen करने की आवश्यकता नहीं है)। - डीबी में कम जगह का उपयोग करता है - डीबी से ऐप

और मुझे क्या याद आया है और आप इसे कैसे करेंगे/करेंगे?

संपादित करें:

मैं सिर्फ क्या जवाब में एक गलतफहमी की तरह दिखता है स्पष्ट करने के लिए करना चाहते हैं। स्लग का सही पृष्ठ पर लैंडिंग पर कोई प्रभाव नहीं पड़ता है। इसे समझने के लिए बस इस साइट पर स्लग के किसी हिस्से को काट लें या उलझाएं। उदा .:

PHP/JS - Create thumbnails on the fly or store as files

PHP/JS - Create thumbnails on the fly or store as files

PHP/JS - Create thumbnails on the fly or store as files

सभी एक ही पृष्ठ पर ले जाएगा। स्लग कभी अनुक्रमित नहीं है।

आपको पुराने स्लग को सहेजने की आवश्यकता नहीं होगी। यदि आप उस पृष्ठ पर उतरे हैं जिसमें "पुराना स्लग" था तो आप इसका पता लगा सकते हैं और केवल 301 सही ढंग से "स्लग्ड" पर रीडायरेक्ट कर सकते हैं। उपर्युक्त उदाहरणों में, यदि स्टैक ओवरफ़्लो ने इसे कार्यान्वित किया है, तो जब आप उपरोक्त छिद्रित स्लग के साथ किसी भी लिंक पर उतरते हैं, तो यह वर्तमान स्लग एल्गोरिदम द्वारा उत्पन्न किए गए यूआरएल में स्लग की तुलना करेगा और यदि अलग होगा तो यह 301 करेगा उसी पृष्ठ पर रीडायरेक्ट करें लेकिन नए स्लग के साथ।

याद रखें कि सभी आंतरिक रूप से जेनरेट किए गए लिंक तुरंत नए एल्गोरिदम का उपयोग करेंगे और पुराने पॉइंटिंग से केवल लिंक पुराने स्लग का उपयोग करेंगे।

Answer 1

आपको एक और चीज को ध्यान में रखना पड़ सकता है, यदि आप चाहते हैं कि उपयोगकर्ता/अपने स्वयं के स्लग को परिभाषित करने में सक्षम हो। शायद एल्गोरिदम हमेशा पर्याप्त नहीं है।

यदि ऐसा है तो आप इसे किसी भी तरह डेटाबेस में स्टोर करने की आवश्यकता नहीं है।

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

सबसे लचीला वाला चुनें।

Answer 2

मौजूदा पृष्ठों के लिए स्लग नहीं बदलना वास्तव में एक बुरा विचार होगा? यह शुरुआत के लिए आपके सभी इनलिंक तोड़ देगा।

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

Answer 3

स्लग पीढ़ी के लिए मुझे नहीं लगता कि पीढ़ी का समय एक मुद्दा होना चाहिए, जब तक कि आपका स्लग एल्गोरिदम बेहद जटिल न हो! इसी तरह, भंडारण स्थान कोई मुद्दा नहीं होगा।

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

Answer 4

मल को संभालने के लिए सबसे अच्छा तरीका है केवल डेटाबेस में स्लग की बात हिस्सा स्टोर और गतिशील पीढ़ी के लिए अद्वितीय पहचानकर्ता के साथ मार्ग हिस्सा रखने के लिए है। अन्यथा (यदि आप पूरे यूआरएल या यूरी को स्टोर करते हैं) तो डेटाबेस में सभी स्लग को फिर से लिखना एक बड़ा काम हो सकता है यदि आपने उन्हें कॉल करने के बारे में अपना मन बदल दिया है।

/प्रश्न/807,195/चाहिए-ए-बनाने-ए-स्लग-ऑन-मक्खी या दुकान में db

यह है:

के उदाहरण के रूप में इतना स्लग इस सवाल लेते हैं :

/route/unique-ID/the-speaking-part-thats-not-so-important 

गतिशील हिस्से जाहिर है:

/route/unique-ID/ 

और एक मैं डेटाबेस में संग्रहीत करेंगे रों है बढ़ता हिस्सा:

the-speaking-part-thats-not-so-important 

यह आप हमेशा मार्ग के नाम के बारे में अपना मन बदल और उचित रीडायरेक्ट रहित डेटाबेस के अंदर पहले देखो करने के लिए और आप डाटाबेस परिवर्तन करने को मजबूर नहीं कर रहे हैं करने के लिए अनुमति देता है। अद्वितीय आईडी हमेशा आपका डेटाबेस डेटा अद्वितीय आईडी है ताकि आप इसे सही ढंग से पहचान सकें और आप कारण बता सकते हैं कि आपके मार्ग क्या हैं।

और कैनोलिक टैग सेट करना न भूलें। तो आप इस पेज कोड के अंदर एक बार देख ले, तो यह नहीं है:

<link rel="canonical" href="http://stackoverflow.com/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db" /> 

यह खोज इंजन के मामले में सही पृष्ठ लिंक की पहचान करने और दूसरों की अनदेखी करने के आप डुप्लिकेट सामग्री है की अनुमति देता है।