हालांकि char . के व्यवहार का सही वर्णन करने वाले कई उत्तर पहले से ही मौजूद हैं , मुझे लगता है कि यह कहने की आवश्यकता है कि आपको इसका उपयोग नहीं करना चाहिए तीन विशिष्ट स्थितियों को छोड़कर:
- आप एक निश्चित-लंबाई वाली फ़ाइल या रिपोर्ट बना रहे हैं, और एक
charको एक गैर-शून्य मान निर्दिष्ट कर रहे हैंrpad()को कोड करने की आवश्यकता से बचा जाता है अभिव्यक्ति। उदाहरण के लिए, यदिfirstnameऔरlastnameदोनों कोchar(20). के रूप में परिभाषित किया गया है , फिरfirstname || lastnameलिखने का एक छोटा तरीका हैrpad(firstname,20) || rpad(lastname,20)बनाने के लिएChuck Norris। - आपको स्पष्ट खाली स्ट्रिंग के बीच अंतर करने की आवश्यकता है
''औरnull. आम तौर पर वे Oracle में समान होते हैं, लेकिन असाइन करना''एकchar. के लिए value इसके रिक्त-पैडिंग व्यवहार को ट्रिगर करेगा जबकिnullनहीं होगा, इसलिए यदि अंतर बताना महत्वपूर्ण है, और मैं वास्तव में इसका कोई कारण नहीं सोच सकता, तो आपके पास ऐसा करने का एक तरीका है। - आपका कोड किसी अन्य सिस्टम से पोर्ट किया गया है (या इसके साथ संगत होना चाहिए) जिसके लिए विरासती कारणों से ब्लैंक-पैडिंग की आवश्यकता होती है। उस मामले में आप इसके साथ फंस गए हैं और आपको मेरी सहानुभूति है।
वास्तव में char का उपयोग करने का कोई कारण नहीं है सिर्फ इसलिए कि कुछ लंबाई तय है (उदाहरण के लिए एक Y/N ध्वज या ISO मुद्रा कोड जैसे 'USD' ) यह अधिक कुशल नहीं है, यह स्थान नहीं बचाता है (varchar2 के लिए कोई पौराणिक लंबाई संकेतक नहीं है। , char . के लिए बस एक खाली पैडिंग ओवरहेड है ), और यह किसी को भी छोटे मान दर्ज करने से नहीं रोकता है। (यदि आप 'ZZ ' . दर्ज करते हैं आपके char(3) . में मुद्रा कॉलम, यह बस 'ZZ ' . के रूप में संग्रहीत हो जाएगा ।) यह ओरेकल के कुछ प्राचीन संस्करण के साथ पिछड़ा-संगत भी नहीं है जो एक बार इस पर निर्भर था, क्योंकि ऐसा कभी नहीं था।
और संक्रमण फैल सकता है, (सर्वोत्तम अभ्यास के बाद) आप sales.currency%type जैसी किसी चीज़ का उपयोग करके एक चर घोषणा को एंकर कर सकते हैं . अब आपका l_sale_currency वेरिएबल एक गुप्त char है जो छोटे मानों (या '' . के लिए अदृश्य रूप से रिक्त-गद्देदार हो जाएगा ), जहां l_sale_currency . में अस्पष्ट बग के लिए द्वार खोलना l_refund_currency के बराबर नहीं है भले ही आपने 'ZZ ' . असाइन किया हो उन दोनों को।
कुछ लोगों का तर्क है कि char(n) (जहां n कुछ वर्ण लंबाई है) इंगित करता है कि मान n . होने की उम्मीद है वर्ण लंबे हैं, और यह स्व-दस्तावेजीकरण का एक रूप है। लेकिन निश्चित रूप से यदि आप 3-वर्ण प्रारूप (उदाहरण के लिए, आईएसओ-अल्फा -2 के बजाय आईएसओ-अल्फा -3 देश कोड) के बारे में गंभीर हैं, तो क्या आप डेवलपर्स को देखने देने के बजाय नियम को लागू करने के लिए एक बाधा को परिभाषित नहीं करेंगे। एक char(3) डेटाटाइप और अपने निष्कर्ष निकालें?
CHAR ओरेकल 6 में पेश किया गया था, मुझे यकीन है, एएनएसआई संगतता कारण। संभवत:संभावित ग्राहक यह तय कर रहे हैं कि कौन सा डेटाबेस उत्पाद खरीदना है और एएनएसआई संगतता उनकी चेकलिस्ट पर है (या तब हुआ करता था), और CHAR रिक्त-पैडिंग के साथ एएनएसआई मानक में परिभाषित किया गया है, इसलिए ओरेकल को इसे प्रदान करने की आवश्यकता है। आपको वास्तव में इसका उपयोग नहीं करना चाहिए।
