2013-07-05 2 views
33

Django models.SlugField() है जो हमें कुछ अच्छे दिखने वाले यूआरएल बनाने में मदद करता है। मेरा प्रश्न है कि क्यों एक क्षेत्रDjango में SlugField() क्यों?

लगता है मैं इस मॉडल के रूप में यह निर्दिष्ट करने

class Blog(models.Model): 
    title = models.CharField() 

और अगर मैं स्लग जोड़ना चाहते हैं, मैं सिर्फ

class Blog(models.Model): 
    title = models.CharField() 

    def title_slug(self): 
     return slugify(self.title) 

यूआरएल में इस्तेमाल कर सकते हैं मैं सिर्फ

(r'^blog/(?P<id>\d+)/(?P<slug>[-\w]+)/$', 'app.views.blog_view'), 
का उपयोग कर सकता था

और में देखा गया

def blog_view(request, id ,slug): 
    get_object_or_404(Blog, pk=id) 
    ... 

यूआरएल की तरह

example.com/blog/23/why-iam-here/ दिखेगा

वहाँ तीन बातें हैं कि बनाता है मुझे इस विधि को अपनाना

  1. स्लग फ़ील्ड es विशिष्ट विशिष्टता के साथ आता है।
  2. get_object_or_404(Blog, pk=id)get_object_or_404(Blog, slug=slug) से तेज़ होना चाहिए।
  3. मौजूदा मॉडलों में एक स्लग फ़ील्ड जोड़ना डेटा माइग्रेशन शामिल है।

तो क्यों SlugField()? , गतिशील रूप से स्लग उत्पन्न करने की लागत के अलावा, उपर्युक्त विधि के नुकसान क्या हैं?

उत्तर

29

का उपयोग क्यों SlugField() Django में? क्योंकि:

  1. यह मानव अनुकूल है (उदाहरण के लिए/ब्लॉग/इसके बजाय/1 /)।
  2. शीर्षक, शीर्षक और यूआरएल में स्थिरता बनाने के लिए यह अच्छा एसईओ है।

आपके गतिशील रूप से जेनरेट किए गए स्लग का बड़ा नुकसान, urls.py में स्लग स्वीकार कर रहा है और सही ऑब्जेक्ट प्राप्त करने के लिए स्लग का उपयोग नहीं कर रहा है? यह खराब डिजाइन है।

यदि आप स्लग की आपूर्ति करते हैं और स्वीकार करते हैं, लेकिन उनके खिलाफ जांच न करें, तो आपके पास एक ही सामग्री को लौटने वाले कई यूआरएल हैं। तो /1/उपयोगी-स्लग/ और /1/यह-एएस-ए-बीएस-स्लग/ दोनों एक ही पृष्ठ को वापस कर देंगे।

यह बुरा है क्योंकि यह मनुष्यों के लिए जीवन आसान नहीं बनाता है। आपके आगंतुकों को एक आईडी और कुछ अनावश्यक आपूर्ति करना है। डुप्लिकेट पेज खोज इंजन दुःस्वप्न हैं। कौन सा पृष्ठ सही है? डुप्लिकेट पेज कम रैंक के साथ खत्म हो जाएगा। देखें https://support.google.com/webmasters/answer/40349?hl=en (अंतिम पी)

आप तर्क दे सकते हैं कि आप लगातार अपने स्वयं के सुन्दर रूप से जेनरेट किए गए लिंक लागू करते हैं, लेकिन लोग और बॉट हर समय यूआरएल अनुमान लगाते हैं (अपनी लॉगफाइल देखें)। जब आप सभी स्लग स्वीकार करते हैं तो मनुष्यों और बॉट्स हमेशा सही अनुमान लगाते हैं।

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

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

बोनस: माइग्रेट डेटा को अद्यतन करने के लिए:

from django.template.defaultfilters import slugify 

for obj in Blog.objects.filter(slug=""): 
    obj.slug = slugify(obj.title) 
    obj.save() 
+14

स्टैक ओवरफ्लो एक रीडायरेक्ट का उपयोग करता है (और मुझे यह पसंद है): http://stackoverflow.com/questions/17495299/this-will-be-replaced आपका स्वागत है! – allcaps

+2

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

8

स्लग फ़ील्ड अंतर्निहित विशिष्टता के साथ नहीं आता है।

CharField के साथ कोई अंतर्निहित विशिष्टता नहीं है। यदि आप यह सुनिश्चित करना चाहते हैं कि प्रत्येक पंक्ति डीबी स्तर पर अद्वितीय है तो आपको unique=True निर्दिष्ट करना होगा। आप दोनों एक CharField के साथ ऐसा कर और एक SlugField तो इसका कोई फायदा नहीं चाहिए करने के लिए या तो

get_object_or_404 (ब्लॉग, पी = आईडी) get_object_or_404 (ब्लॉग, स्लग = स्लग) की तुलना में तेजी से होना चाहिए।

आपकी प्राथमिक कुंजी पर एक इंडेक्स के कारण बहुत मामूली अंतर हो सकता है, लेकिन यह शायद नगण्य है। CharField बनाम SlugField का उपयोग करने के साथ इसका कोई लेना-देना नहीं है - आपने अभी एक अलग यूआरएल बनाया है जो id लेता है और लुकअप करने के लिए इसका उपयोग कर रहा है।

मौजूदा मॉडलों में एक स्लग फ़ील्ड जोड़ना डेटा माइग्रेशन शामिल है।

एक मौजूदा मॉडल के लिए एक CharField जोड़ने से भी एक डेटा प्रवास के लिए आवश्यक कोई फायदा नहीं है इसलिए यहाँ।


SlugFields बस सत्यापन का एक अतिरिक्त बिट के साथ CharField हैं। Look at the code। आप डीजेगो के डीआरवाई के स्वर्णिम शासन को तोड़ रहे हैं - खुद को दोहराएं मत।

इसके अलावा, यदि आप केवल CharField का उपयोग करते हैं तो आपको फॉर्म स्तर पर कोई सत्यापन नहीं मिलता है, इसलिए आप आसानी से "स्लग" बना सकते हैं जो स्लग सत्यापन के अनुरूप नहीं है, यानी इसमें रिक्त स्थान हो सकते हैं या वे वर्ण जिन्हें URL में अनुमति नहीं है।

इस दृष्टिकोण के साथ, यदि आप अपना शीर्षक बदलते हैं, तो आपका यूआरएल बदल गया है और अब आपके सभी पुराने लिंक मर गए हैं। एक स्लग फील्ड होने से यह रोकता है।

आप यहाँ खुद के लिए और अधिक मुसीबत बना रहे हैं - बस SlugField

+1

अपने मूल्यवान टिप्पणी के लिए धन्यवाद, मान्यता पर अंक और सूखी अच्छा था। लेकिन मेरा वास्तविक प्रश्न चारफिल्ड और स्लगफील्ड के बीच का अंतर नहीं था, लेकिन डेटाबेस में स्लगफिल्ड होने और गतिशील रूप से एक उत्पन्न करने का अंतर था। –

+1

मैंने जवाब दिया है: "स्लगफिल्ड्स केवल सत्यापन के अतिरिक्त चर के साथ चारफिल्ड हैं" - डीबी स्तर –

+0

में कोई अंतर नहीं है क्या स्लगफ़िल्ल्ड डिफ़ॉल्ट रूप से डीबी इंडेक्स नहीं बनाता है? – chhantyal

संबंधित मुद्दे