SQL केस संवेदनशील है। मैंने MySQL और SQL सर्वर का उपयोग किया है, जो दोनों के मामले में संवेदनशील लग रहे हैं। क्या हमेशा ऐसा ही होता है? क्या मानक केस-संवेदनशीलता को परिभाषित करता है?
जवाबों:
एसक्यूएल कीवर्ड केस-संवेदी (हैं SELECT, FROM, WHERE, आदि), लेकिन अक्सर सभी बड़े अक्षरों में लिखा जाता है। हालाँकि कुछ सेटअप तालिका और स्तंभ नाम केस-संवेदी होते हैं। इसे सक्षम / अक्षम करने के लिए MySQL के पास एक विन्यास विकल्प है। आमतौर पर केस-संवेदी तालिका और स्तंभ नाम लिनक्स MySQL पर डिफ़ॉल्ट होते हैं और केस-असंवेदनशील विंडोज पर डिफ़ॉल्ट होते थे, लेकिन अब इंस्टॉलर ने सेटअप के दौरान इस बारे में पूछा। MSSQL के लिए यह डेटाबेस के कोलाज सेटिंग का एक कार्य है।
Sql Server में यह एक विकल्प है । इसे चूसते हुए।
मैं MySql के बारे में निश्चित नहीं हूं।
SQL92 विनिर्देश राज्यों पहचानकर्ता उद्धृत है कि हो सकता है, या गैर उद्धृत। यदि दोनों पक्ष अयोग्य हैं तो वे हमेशा केस-असंवेदनशील होते हैं, उदाहरण के लिए table_name == TAble_nAmE।
हालांकि उद्धृत पहचानकर्ता मामले के प्रति संवेदनशील होते हैं, उदाहरण के लिए "table_name" != "TAble_naME"। इसके अलावा कल्पना के आधार पर अगर आप उद्धृत किए गए पहचानकर्ताओं की तुलना करना चाहते हैं, तो अयोग्य और उद्धृत पहचानकर्ताओं को एक ही माना जा सकता है, यदि अयोग्य पात्रों को अपरकेस, जैसे TABLE_NAME == "TABLE_NAME", TABLE_NAME != "table_name"या , लेकिन TABLE_NAME != "TAble_NaMe"।
यहाँ युक्ति का प्रासंगिक हिस्सा है (खंड 5.2.13):
13)A <regular identifier> and a <delimited identifier> are equiva-
lent if the <identifier body> of the <regular identifier> (with
every letter that is a lower-case letter replaced by the equiva-
lent upper-case letter or letters) and the <delimited identifier
body> of the <delimited identifier> (with all occurrences of
<quote> replaced by <quote symbol> and all occurrences of <dou-
blequote symbol> replaced by <double quote>), considered as
the repetition of a <character string literal> that specifies a
<character set specification> of SQL_TEXT and an implementation-
defined collation that is sensitive to case, compare equally
according to the comparison rules in Subclause 8.2, "<comparison
predicate>".ध्यान दें, कि SQL मानक के अन्य भागों की तरह, सभी डेटाबेस इस खंड का पूरी तरह से पालन नहीं करते हैं। उदाहरण के लिए PostgreSQL अपरकेस के बजाय सभी अनछुए पहचानकर्ताओं को संग्रहीत करता है, इसलिए table_name == "table_name"(जो मानक के बिल्कुल विपरीत है)। इसके अलावा कुछ डेटाबेस हर समय केस-असंवेदनशील होते हैं, या केस-सेंसिटिवनेस डीबी में कुछ सेटिंग पर निर्भर करते हैं या सिस्टम के कुछ गुणों पर निर्भर होते हैं, आमतौर पर फाइलसिस्टम केस-सेंसिटिव होता है या नहीं।
ध्यान दें कि कुछ डेटाबेस टूल हर समय उद्धृत किए गए पहचानकर्ताओं को भेज सकते हैं, इसलिए ऐसे उदाहरणों में जहां आप कुछ टूल द्वारा बनाई गई क्वेरीज़ को मिलाते हैं (जैसे कि लिक्विबेस या अन्य डीबी माइग्रेशन टूल द्वारा बनाई गई क्रिएट टेबल क्वेरी), हाथ से बने प्रश्नों के साथ (जैसे एक साधारण JBCBC चुनें) अपने आवेदन में) आपको यह सुनिश्चित करना होगा कि मामले सुसंगत हैं, विशेष रूप से डेटाबेस पर जहां उद्धृत और निर्विवाद पहचानकर्ता अलग हैं (DB2, PostgreSQL, आदि)
मेरी समझ यह है कि SQL मानक केस-असंवेदनशीलता के लिए कहता है। मेरा मानना है कि कोई भी डेटाबेस पूरी तरह से मानक का पालन नहीं करता है।
MySQL के पास इसके "सख्त मोड" के हिस्से के रूप में एक कॉन्फ़िगरेशन सेटिंग है (कई सेटिंग्स का एक पकड़ा बैग जो केस सेंसिटिव या असंवेदनशील टेबल नामों के लिए MySQL को अधिक मानकों-अनुरूप बनाता है)। इस सेटिंग के बावजूद, कॉलम नाम अभी भी केस-असंवेदनशील हैं, हालांकि मुझे लगता है कि यह प्रभावित करता है कि कॉलम-नाम कैसे प्रदर्शित होते हैं। मेरा मानना है कि यह सेटिंग आरडीबीएमएस उदाहरण के भीतर सभी डेटाबेस में उदाहरण के लिए विस्तृत है, हालांकि मैं आज इसकी पुष्टि करने के लिए शोध कर रहा हूं (और जवाब नहीं मिलने की उम्मीद है)।
मुझे पसंद है कि ओरेकल कैसे इसे बेहतर तरीके से संभालता है। सीधे SQL में, टेबल और कॉलम नाम जैसे पहचानकर्ता मामले असंवेदनशील होते हैं। हालांकि, अगर किसी कारण से आप वास्तव में स्पष्ट आवरण प्राप्त करने की इच्छा रखते हैं, तो आप पहचानकर्ता को दोहरे-उद्धरणों में संलग्न कर सकते हैं (जो स्ट्रिंग डेटा को संलग्न करने के लिए उपयोग किए गए एकल-उद्धरणों से ओरेकल एसक्यूएल में काफी भिन्न हैं)। इसलिए:
SELECT fieldName
FROM tableName;tablename से फ़ील्डनाम क्वेरी करेगा , लेकिन
SELECT "fieldName"
FROM "tableName";क्वेरी करेगा FIELDNAME से TableName ।
मुझे पूरा यकीन है कि आप इस तंत्र का उपयोग एक पहचानकर्ता में रिक्त स्थान या अन्य गैर-मानक वर्ण डालने के लिए भी कर सकते हैं।
इस स्थिति में यदि किसी कारणवश आपको स्पष्ट रूप से आवरण वाली मेज और स्तंभ नाम वांछनीय लगे तो यह आपके लिए उपलब्ध था, लेकिन फिर भी यह कुछ ऐसा था जिसके खिलाफ मैं अत्यधिक सावधानी बरतता।
जब मैंने ओरेकल को दैनिक आधार पर उपयोग किया तो मेरा सम्मेलन यह था कि मैं सभी ओरेकल एसक्यूएल कीवर्ड को अपरकेस और लोअरकेस में सभी पहचानकर्ताओं को डाल दूंगा। दस्तावेज़ीकरण में मैं सभी तालिका और स्तंभ नाम अपरकेस में रखूंगा। यह करने में सक्षम होने के लिए यह बहुत सुविधाजनक और पठनीय था (हालांकि कभी-कभी कोड में कई राजधानियों को टाइप करने के लिए एक दर्द - मुझे यकीन है कि मुझे यहां मदद करने के लिए एक संपादक सुविधा मिल सकती है)।
मेरी राय में MySQL विभिन्न प्लेटफार्मों पर इस बारे में अलग करने के लिए विशेष रूप से खराब है। हमें विंडोज पर डेटाबेस को डंप करने और उन्हें UNIX में लोड करने में सक्षम होने की आवश्यकता है, और ऐसा करना एक आपदा है अगर विंडोज पर इंस्टॉलर RDBMS को केस-सेंसिटिव मोड में डालना भूल गया। (निष्पक्ष होने के लिए, इस आपदा का कारण यह है कि हमारे कोडर्स ने खराब निर्णय लिया है, बहुत पहले UNIX पर MySQL की केस-सेंसिटिविटी पर भरोसा करने के लिए।) जिन लोगों ने विंडोज MySQL इंस्टॉलर लिखा था, उन्होंने इसे वास्तव में सुविधाजनक बना दिया। विंडोज की तरह, और लोगों को यह कहने के लिए एक चेकबॉक्स देने की ओर बढ़ने के लिए बहुत अच्छा था "क्या आप सख्त मोड को चालू करना चाहेंगे और MySQL को अधिक मानकों-अनुरूप बना सकते हैं?" लेकिन MySQL के लिए यह बहुत सुविधाजनक है कि मानक से इतने अलग तरीके से अलग किया जाए, और फिर विभिन्न प्लेटफार्मों पर अपने स्वयं के वास्तविक मानक से अलग और चारों ओर मोड़कर मामलों को बदतर बनाते हैं। मुझे यकीन है कि अलग-अलग लिनक्स वितरणों पर इसे और अधिक जटिल किया जा सकता है, क्योंकि अलग-अलग डिस्ट्रो के लिए पैक करने वालों ने संभवत: कई बार अपनी पसंदीदा MySQL कॉन्फ़िगरेशन सेटिंग्स को शामिल किया है।
यहाँ एक और SO प्रश्न है जो इस बात पर चर्चा करता है कि RDBMS में केस-सेंसिटिविटी वांछनीय है या नहीं।
नहीं। MySQL संवेदनशील नहीं है, और न ही SQL मानक है। आदेशों को ऊपरी तौर पर लिखना केवल आम बात है।
अब, यदि आप तालिका / स्तंभ नामों के बारे में बात कर रहे हैं, तो हाँ वे हैं, लेकिन स्वयं आदेश नहीं।
इसलिए
SELECT * FROM foo;के समान है
select * from foo;लेकिन ऐसा नहीं है
select * from FOO;मुझे यह ब्लॉग पोस्ट बहुत मददगार लगी (मैं लेखक नहीं हूँ)। सारांश (कृपया पढ़ें, हालांकि):
... सीमांकित पहचानकर्ता मामले के प्रति संवेदनशील होते हैं ("table_name"! = "Table_Name"), जबकि गैर उद्धृत पहचानकर्ता नहीं होते हैं, और ऊपरी मामले में बदल जाते हैं (table_name => TABLE_NAME)।
उन्होंने पाया कि DB2, Oracle और Interbase / Firebird 100% संगत हैं:
PostgreSQL ... हर अपरिपक्व पहचानकर्ता को अपरकेस के बजाय कम कर देता है। MySQL ... फाइल सिस्टम आश्रित। SQLite और SQL सर्वर ... तालिका और फ़ील्ड नामों के मामले को निर्माण पर संरक्षित किया जाता है, लेकिन बाद में उन्हें पूरी तरह से अनदेखा कर दिया जाता है।
SQL कीवर्ड केस असंवेदनशील हैं।
तालिकाओं, स्तंभों आदि के नाम, एक केस सेंसिटिविटी है, जो डेटाबेस पर निर्भर है - आपको शायद यह मान लेना चाहिए कि वे केस सेंसिटिव हैं, जब तक कि आप अन्यथा नहीं जानते (कई डेटाबेस में वे हालांकि नहीं हैं; MySQL टेबल में नाम SOMETIMES केस सेंसिटिव हैं, लेकिन अधिकांश अन्य हैं। नाम नहीं हैं)।
=,>, <आदि का उपयोग करके डेटा की तुलना करना, एक केस अवेयरनेस है जो कि कोलाज सेटिंग्स पर निर्भर है जो व्यक्तिगत डेटाबेस, टेबल या यहां तक कि कॉलम में उपयोग किए गए हैं। हालांकि, सामान्य रूप से टकराव को डेटाबेस के अनुरूप बनाए रखना सामान्य है। हमारे पास कुछ कॉलम हैं जिन्हें केस-संवेदी मूल्यों को संग्रहीत करने की आवश्यकता है; उनके पास विशेष रूप से एक कोलाज है।
दोनों दुनिया के सर्वश्रेष्ठ हैं
इन दिनों आप सिर्फ लोअरकेस में अपने सभी sql स्टेटमेंट लिख सकते हैं और अगर आपको कभी भी इसे फॉर्मेट करने की आवश्यकता है तो बस एक प्लगइन स्थापित करें जो आपके लिए इसे करेगा। यह तभी लागू होता है जब आपके कोड संपादक के पास वे प्लग इन उपलब्ध हों। VSCode के पास कई एक्सटेंशन हैं जो ऐसा कर सकते हैं।