Django CharField बनाम TextField


302

CharField()और TextField()Django में क्या अंतर है ? प्रलेखन का कहना है कि CharField()छोटे तार के लिए इस्तेमाल किया जाना चाहिए और TextField()बड़ा तार के लिए इस्तेमाल किया जाना चाहिए। ठीक है, लेकिन "छोटी" और "बड़ी" के बीच रेखा कहाँ खींची गई है? यहाँ हुड के तहत क्या चल रहा है जो इस मामले को बनाता है?

जवाबों:


354

यह RDBMS's varchar(या समान) के बीच अंतर है - जिन्हें आमतौर पर अधिकतम लंबाई के साथ निर्दिष्ट किया जाता है, और प्रदर्शन या भंडारण के मामले में अधिक कुशल हो सकता है - और text(या समान) प्रकार - ये आमतौर पर केवल हार्डकोड कार्यान्वयन सीमाओं द्वारा सीमित होते हैं (नहीं एक DB स्कीमा)।

PostgreSQL 9, विशेष रूप से, बताता है कि "इन तीन प्रकारों के बीच कोई प्रदर्शन अंतर नहीं है" , लेकिन AFAIK में उदाहरण के लिए कुछ अंतर हैं MySQL, इसलिए यह कुछ ध्यान में रखना है।

अंगूठे का एक अच्छा नियम यह है कि आप का उपयोग CharFieldतब करते हैं जब आपको अधिकतम लंबाई को सीमित करने की आवश्यकता होती है, TextFieldअन्यथा।

यह वास्तव में Django- विशिष्ट भी नहीं है।


42
और इसके विपरीत, यदि आप CharField का उपयोग करते हैं, तो आपके पास अधिकतम लंबाई होनी चाहिए
सैम स्वेनबॉर्गोक्रिस्टीनेंसन

17
मैंने पाया है कि TextFieldडिफ़ॉल्ट रूप से उपयोग करने से आपके ऐप की पोर्टेबिलिटी प्रभावित हो सकती है। Postgres पर प्रदर्शन हिट नहीं हो सकता है, लेकिन Oracle इसे स्टोर करेगा, CLOBजिसमें कुछ झुंझलाहट हैं, जैसे कि WHERE के बयानों में फ़ील्ड का उपयोग करने में सक्षम नहीं है। बस कुछ विचार करने के लिए।
रोब

3
एक को यह भी विचार करना चाहिए कि ओरेकल में 2000 से अधिक CharFieldनहीं हो सकता है max_length, या यह एक ORA-00910: specified length too long for its datatypeत्रुटि जारी करता है।
दीनी

फ़ील्ड विशेषताओं पर विचार करते समय, ध्यान देने योग्य बात, कि पोस्टग्रोज़ डॉक्स भी कहते हैं (जोर मेरा): "संग्रहीत किया जाने वाला सबसे लंबा संभव चरित्र स्ट्रिंग लगभग 1 जीबी है। (अधिकतम मूल्य जिसे डेटा प्रकार घोषणा में n के लिए अनुमति दी जाएगी। इससे कम [...] यदि आप किसी विशिष्ट ऊपरी सीमा के साथ लंबे तारों को संग्रहीत करने की इच्छा रखते हैं , तो मनमाना लंबाई सीमा बनाने के बजाय लंबाई निर्दिष्ट किए बिना पाठ या वर्ण का उपयोग करें । "
iff_or

3
मेरा मानना ​​है कि django में दोनों के बीच वास्तव में महत्वपूर्ण अंतर यह है कि एक दृश्य क्षेत्र को कैसे संभालेगा। एक सामान्य संपादन दृश्य में TextField एक बहु-पंक्ति पुन: प्रयोज्य इनपुट के रूप में प्रस्तुत करेगा; जबकि चारफिल्ड सिंगल लाइन इनपुट है। मैंने TextField के लिए django स्रोत को नहीं देखा है, लेकिन मैं यह मानने जा रहा हूं कि यदि कोई उत्पन्न HTML एक TextField से जुड़ा हुआ है, तो यह बहुस्तरीय मल्टीलाइन टेक्स्ट को ठीक से हेरफेर करने का एक तरीका लागू करेगा।
मिशेल वॉल्स

36

कुछ मामलों में यह बंधा हुआ है कि फ़ील्ड का उपयोग कैसे किया जाता है। कुछ DB इंजनों में क्षेत्र के अंतर यह निर्धारित करते हैं कि आप (और यदि) क्षेत्र में पाठ की खोज कैसे करते हैं। CharFields आमतौर पर उन चीजों के लिए उपयोग की जाती हैं जो खोज योग्य हैं, जैसे यदि आप "एक प्लस दो" स्ट्रिंग में "एक" की खोज करना चाहते हैं। चूंकि तार छोटे होते हैं इसलिए वे इंजन के माध्यम से खोज करने में कम समय लेते हैं। TextFields आमतौर पर के माध्यम से खोजा जा करने के लिए नहीं हैं (जैसे शायद एक ब्लॉग के शरीर) लेकिन पाठ का बड़ा हिस्सा पकड़ के लिए होती हैं। अब यह अधिकांश DB इंजन पर निर्भर करता है और Postgres की तरह यह कोई फर्क नहीं पड़ता।

यहां तक ​​कि अगर यह कोई फर्क नहीं पड़ता, अगर आप ModelForms का उपयोग करते हैं तो आपको फॉर्म में एक अलग प्रकार का संपादन फ़ील्ड मिलता है। ModelForm एक HTML पाठ का निर्माण करेगा एक पाठ के एक पंक्ति के आकार के लिए एक CharField और एक पाठ के लिए बहुपरत।


2
यह अब तक का सबसे अच्छा विवरण है क्योंकि इसमें उल्लेख किया गया है कि यह एक रूप में क्षेत्र कैसे उत्पन्न करता है। चारफील्ड सिर्फ एक लाइन इनपुट होगा, लेकिन TextField एक res बहुभाषी होगा। TextField समझ में आता है जब आप मुख्य रूप से सामान्य वर्ग के विचारों को लागू करते हैं। यह वर्णन क्षेत्र या जैसे के लिए बहुत अच्छा काम करता है। मुझे यह भी पसंद है कि कैसे रेंडरबॉक्स ने उल्लेख किया कि आप इसे किसी भी फिल्टर / खोजों के लिए उपयोग नहीं करना चाहेंगे।
मिशेल वॉल्स

8

उदाहरण के लिए।,। नीचे एक मॉडल में 2 फ़ील्ड जोड़े गए हैं ..

description = models.TextField(blank=True, null=True)
title = models.CharField(max_length=64, blank=True, null=True)

माइग्रेशन लागू होने पर नीचे दिए गए mysql क्वेरी को निष्पादित किया जाता है।


के लिए TextField(विवरण) क्षेत्र एक के रूप में परिभाषित किया गया हैlongtext

ALTER TABLE `sometable_sometable` ADD COLUMN `description` longtext NULL;

TextFieldMySQL की अधिकतम लंबाई स्ट्रिंग-प्रकार-अवलोकन के अनुसार 4GB है ।


के लिए CharField(शीर्षक) MAX_LENGTH () की आवश्यकता के रूप में परिभाषित किया गया हैvarchar(64)

ALTER TABLE `sometable_sometable` ADD COLUMN `title` varchar(64) NULL;
ALTER TABLE `sometable_sometable` ALTER COLUMN `title` DROP DEFAULT;

1
निट: Django डॉक्स की सिफारिश: Avoid using null on string-based fields such as CharField and TextField: docs.djangoproject.com/en/2.0/ref/models/fields/#null तो यह सबसे अच्छा रखने के लिए null=False
modulitos

7

CharField255वर्णों की अधिकतम गति है जबकि वर्णों की TextFieldतुलना में अधिक पकड़ हो सकती है 255TextFieldजब आपके पास इनपुट के रूप में एक बड़ा स्ट्रिंग हो तो उपयोग करें । यह जानना अच्छा है कि जब max_lengthपैरामीटर को इसमें पारित किया TextFieldजाता है, तो TextAreaविजेट के लिए लंबाई सत्यापन पारित किया जाता है ।


" VARCHARस्तंभ प्रकारों के साथ संग्रहीत किसी भी फ़ील्ड में max_length255 वर्णों तक सीमित है यदि आप अद्वितीय = क्षेत्र के लिए सही उपयोग कर रहे हैं। " (मेरा जोर दिया गया है)
l0b0

-4

मुझे एक अजीब समस्या थी और एक अप्रिय अजीब अंतर समझ में आया: जब मुझे उपयोगकर्ता से चारफिल्ड के रूप में एक यूआरएल मिलता है और तब एचटीएमएल द्वारा एचटीएमएल टैग में इसका उपयोग किया जाता है, यह उस यूआरएल को मेरे यूआरएल में जोड़ता है और यही मैं नहीं चाहता। लेकिन जब मैं इसे टेक्स्टफील्ड द्वारा करता हूं तो यह केवल उस URL को पास करता है जिसे उपयोगकर्ता ने दर्ज किया था। इन्हें देखें: मेरी वेबसाइट का पता:http://myweb.com

चारफील्ड एंट्री: http://some-address.com

उस पर क्लिक करते समय: http://myweb.comhttp://some-address.com

TextField में प्रवेश: http://some-address.com

उस पर क्लिक करते समय: http://some-address.com

मुझे यह उल्लेख करना होगा कि URL दो तरह से DB में समान रूप से सहेजा गया है, लेकिन मुझे नहीं पता कि उन पर क्लिक करने पर परिणाम अलग क्यों होता है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.