string - PostgreSQL: पाठ और वर्चर के बीच अंतर(चरित्र अलग-अलग)




text types (6)

text डेटा प्रकार और character varying ( varchar ) डेटा प्रकारों के बीच क्या अंतर है?

दस्तावेज के अनुसार

यदि चरित्र भिन्न होता है तो लंबाई विनिर्देश के बिना प्रयोग किया जाता है, प्रकार किसी भी आकार के तार स्वीकार करता है। उत्तरार्द्ध एक PostgreSQL एक्सटेंशन है।

तथा

इसके अलावा, PostgreSQL टेक्स्ट प्रकार प्रदान करता है, जो किसी भी लंबाई के तारों को संग्रहीत करता है। हालांकि टाइप टेक्स्ट SQL मानक में नहीं है, कई अन्य SQL डेटाबेस प्रबंधन प्रणालियों में भी यह है।

तो क्या अंतर है?


2016 के लिए अद्यतन बेंचमार्क (पृष्ठ 9 .5 +)

और "शुद्ध एसक्यूएल" बेंचमार्क का उपयोग (किसी बाहरी स्क्रिप्ट के बिना)

  1. UTF8 के साथ किसी string_generator का उपयोग करें

  2. मुख्य मानक:

    2.1। सम्मिलित करें

    2.2। तुलना और गिनती चुनें

CREATE FUNCTION string_generator(int DEFAULT 20,int DEFAULT 10) RETURNS text AS $f$
  SELECT array_to_string( array_agg(
    substring(md5(random()::text),1,$1)||chr( 9824 + (random()*10)::int )
  ), ' ' ) as s
  FROM generate_series(1, $2) i(x);
$f$ LANGUAGE SQL IMMUTABLE;

विशिष्ट परीक्षण तैयार करें (उदाहरण)

DROP TABLE IF EXISTS test;
-- CREATE TABLE test ( f varchar(500));
-- CREATE TABLE test ( f text); 
CREATE TABLE test ( f text  CHECK(char_length(f)<=500) );

एक बुनियादी परीक्षण करें:

INSERT INTO test  
   SELECT string_generator(20+(random()*(i%11))::int)
   FROM generate_series(1, 99000) t(i);

और अन्य परीक्षण,

CREATE INDEX q on test (f);

SELECT count(*) FROM (
  SELECT substring(f,1,1) || f FROM test WHERE f<'a0' ORDER BY 1 LIMIT 80000
) t;

... और EXPLAIN ANALYZE उपयोग करें। मेरे परिणाम: औसतन, वही।


PostgreSQL मैनुअल पर

इन तीन प्रकारों में कोई प्रदर्शन अंतर नहीं है, रिक्त-पैड किए गए प्रकार का उपयोग करते समय स्टोरेज स्पेस के अलावा, और कुछ अतिरिक्त CPU चक्र, लंबाई-बाध्य कॉलम में संग्रहीत करते समय लंबाई की जांच करने के लिए। जबकि चरित्र (एन) में कुछ अन्य डेटाबेस सिस्टम में प्रदर्शन फायदे हैं, पोस्टग्रेएसक्यूएल में ऐसा कोई फायदा नहीं है; वास्तव में चरित्र (एन) आमतौर पर अतिरिक्त भंडारण लागत के कारण तीनों में से सबसे धीमा होता है। ज्यादातर स्थितियों में टेक्स्ट या चरित्र को अलग-अलग इस्तेमाल किया जाना चाहिए।

मैं आमतौर पर पाठ का उपयोग करता हूं

संदर्भ: http://www.postgresql.org/docs/current/static/datatype-character.html


टेक्स्ट और वर्चर में अलग-अलग प्रकार के रूपांतरण होते हैं। मैंने देखा है कि सबसे बड़ा प्रभाव पिछली जगहों का संचालन कर रहा है। उदाहरण के लिए ...

select ' '::char = ' '::varchar, ' '::char = ' '::text, ' '::varchar = ' '::text

true, false, true और true, false, true नहीं true, true, true जैसा आप उम्मीद कर सकते हैं।


प्रलेखन में " वर्ण प्रकार " के रूप में, varchar(n) , char(n) , और text सभी एक ही तरीके से संग्रहीत हैं। एकमात्र अंतर यह है कि लम्बाई जांचने के लिए अतिरिक्त चक्र की आवश्यकता होती है, अगर कोई दिया जाता है, और यदि अतिरिक्त char(n) लिए पैडिंग की आवश्यकता होती है तो अतिरिक्त स्थान और समय की आवश्यकता होती है।

हालांकि, जब आपको केवल एक ही चरित्र को स्टोर करने की आवश्यकता होती है, तो विशेष प्रकार "char" का उपयोग करने के लिए थोड़ा सा प्रदर्शन लाभ होता है (डबल-कोट्स रखें - वे प्रकार के नाम का हिस्सा हैं)। आपको मैदान में तेजी से पहुंच मिलती है, और लंबाई को स्टोर करने के लिए कोई ओवरहेड नहीं होता है।

मैंने निचले-केस वर्णमाला से चुने गए 1,000,000 यादृच्छिक "char" की एक तालिका बनाई है। एक आवृत्ति वितरण प्राप्त करने के लिए एक क्वेरी ( select count(*), field ... group by field ) लगभग 650 मिलीसेकंड लेता है, एक text फ़ील्ड का उपयोग कर उसी डेटा पर लगभग 760 बनाम।


हुड के नीचे कोई अंतर नहीं है, यह सभी varlena ( परिवर्तनीय लंबाई सरणी ) है।

Depesz से इस आलेख को देखें: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

कुछ हाइलाइट्स:

इसे सब कुछ समेटने के लिए:

  • चार (एन) - n से कम मूल्यों से निपटने के दौरान बहुत अधिक जगह लेता है (पैड उन्हें n ), और पीछे की जगह जोड़ने के कारण सूक्ष्म त्रुटियों का कारण बन सकता है, साथ ही सीमा को बदलने में समस्याग्रस्त है
  • वर्कर (एन) - लाइव वातावरण में सीमा को बदलने में समस्याग्रस्त है (तालिका को बदलने के दौरान विशेष लॉक की आवश्यकता है)
  • वर्कर - बस पाठ की तरह
  • पाठ - मेरे लिए एक विजेता - ओवर (एन) डेटा प्रकार क्योंकि इसमें उनकी समस्याएं नहीं हैं, और वर्चर पर - क्योंकि इसका अलग नाम है

आलेख यह दिखाने के लिए विस्तृत परीक्षण करता है कि सभी 4 डेटा प्रकारों के लिए आवेषण और चयन का प्रदर्शन समान है। यह आवश्यक होने पर लंबाई को बाधित करने के वैकल्पिक तरीकों पर एक विस्तृत रूप भी लेता है। फंक्शन आधारित बाधाएं या डोमेन लंबाई की बाधा की तत्काल वृद्धि का लाभ प्रदान करते हैं, और आधार पर कि एक स्ट्रिंग लंबाई बाधा कम करने के आधार पर दुर्लभ है, depesz निष्कर्ष निकाला है कि उनमें से एक आमतौर पर लंबाई सीमा के लिए सबसे अच्छा विकल्प है।


character varying(n) , varchar(n) - (दोनों एक ही)। त्रुटि को उठाए बिना मूल्य को एन अक्षरों में छोटा कर दिया जाएगा।

character(n) , char(n) - (दोनों एक ही)। निश्चित लंबाई और लंबाई के अंत तक रिक्त स्थान के साथ पैड होगा।

text - असीमित लंबाई।

उदाहरण:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

हमें परिणाम मिलते हैं:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2




varchar