2008-10-16 9 views
9

क्या SQL डेटाबेस में वर्चर से टेक्स्ट का उपयोग करना कम कुशल है?डेटाबेस: "टेक्स्ट" फ़ील्ड "वर्कर" से कम कुशल हैं?

यदि ऐसा है तो क्यों?

यदि नहीं, तो आप हमेशा टेक्स्ट का उपयोग क्यों नहीं करेंगे?

मैं यहां एक विशिष्ट डेटाबेस को लक्षित नहीं कर रहा हूं लेकिन ऑरैकल शायद सबसे प्रासंगिक है, हालांकि मैं अवधारणा के सबूत के हिस्से के रूप में समय के लिए MySQL पर परीक्षण कर रहा हूं।

+0

मुझे लगता है कि यह सब कुछ कहा गया है, माईएसक्यूएल के मामले में, वर्चर्स कॉलम के लिए "इंडेक्स रीड" भी है और टेक्स्ट कॉलम के लिए हमेशा "पंक्ति पढ़ने" भी होता है। जो टेक्स्ट-कॉलम पर एक LIKE-query धीमा बनाता है। – Till

उत्तर

4

माइक्रोसॉफ्ट here

से

ntext, पाठ, और छवि डेटा प्रकार Microsoft SQL सर्वर के भविष्य के संस्करण में हटा दिया जाएगा। का उपयोग नए विकास कार्य में इन डेटा प्रकारों से बचें, और वर्तमान में उनका उपयोग करने वाले अनुप्रयोगों को संशोधित करने की योजना बनाएं। nvarchar (अधिकतम), वर्चर (अधिकतम), और इसके बजाय varbinary (अधिकतम) का उपयोग करें।

जब आप पाठ के ऊपर varchar(max) का उपयोग आप WHERE खंड में उपयोग कर सकते हैं, क्योंकि वे अपने छोटे समकक्षों, varchar,nvarchar and varbinary रूप में एक ही काम करते हैं। पाठ

  • उपयोग ntext
  • उपयोग varbinary के बजाय nvarchar (अधिकतम) के बजाय

    • उपयोग varchar (max) (अधिकतम: नीचे क्या विरोध किया के रूप में इस्तेमाल किया जाना चाहिए की एक छोटी सूची क्या किया जाना था है) छवि के बजाय
  • 1

    संक्षिप्त उत्तर है: हाँ, वे कम कुशल हैं।

    लंबा, अधिक जटिल जवाब है:

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

    मुझे पता है कि MySQL निश्चित लंबाई तालिका पंक्तियों के साथ तेज़ी से काम करता है, लेकिन आपको यह बताना होगा कि तालिका को पहले निश्चित लंबाई तालिका के रूप में माना जा सकता है। वास्तविक संख्या से संबंधित होने में सक्षम होने के लिए मेरे पास अन्य डीबीएमएस के साथ वास्तव में कोई व्यावहारिक अनुभव नहीं है। लेकिन रिकॉर्ड्स के साथ तालिकाओं पर (लाखों या अधिक) रिकॉर्ड रिकॉर्ड करते हैं, इससे महत्वपूर्ण अंतर हो सकता है। हालांकि छोटे टेबलों में कोई व्यावहारिक अंतर नहीं होगा।

    +0

    यह 'टेक्स्ट' बनाम 'CHAR' है। ओपी ने 'टेक्स्ट' बनाम 'वचर' के लिए कहा। – dan04

    1

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

    शायद इंडेक्सिंग और पूछताछ के प्रभाव भी हैं, लेकिन फिर यह आपके द्वारा उपयोग किए जा रहे विशेष आरडीबीएमएस पर निर्भर करेगा।

    2

    PostgreSQL documentation says:

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

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

    • कोई संबंधित समस्या नहीं^_^