2008-10-22 13 views
20

हमने DEVEL से टेस्ट में SQL सर्वर 2005 डेटाबेस को 'माइग्रेट किया' है। किसी भी तरह माइग्रेशन प्रक्रिया के दौरान डीबी को असंवेदनशील से संवेदनशील स्थिति में बदल दिया गया था - इसलिए अधिकांश एसक्यूएल प्रश्न शानदार रूप से टूट गए।क्या केस संवेदनशील डेटाबेस के लिए कोई लाभ हैं?

मैं क्या जानना चाहता हूं, क्या कोई केस संवेदनशील स्कीमा रखने के लिए कोई स्पष्ट लाभ है?

नोट: इसके द्वारा मेरा मतलब है टेबल नाम, कॉलम नाम, संग्रहीत प्रो नाम आदि। मैं वास्तव में टेबल में संग्रहीत डेटा का जिक्र नहीं कर रहा हूं।

पहले निरीक्षण में, मुझे एक वैध कारण नहीं मिल रहा है जो असंवेदनशीलता के मामले में लाभ प्रदान करता है।

उत्तर

12

मुझे पता चला कि हम इसे केस संवेदनशील क्यों बनाते हैं। यह सुनिश्चित करना है कि जब हम इसे क्लाइंट साइट पर तैनात करते हैं, तो हमारे डीबी इस बात पर ध्यान दिए बिना कि क्लाइंट का SQL सर्वर केस संवेदनशील है या नहीं।

यह एक उत्तर है जिसे मैं उम्मीद नहीं कर रहा था।

+0

यही कारण है कि हम निश्चित रूप से ऐसा करेंगे। – nickd

+2

दूसरा उत्तर: अपने टेस्ट सिस्टम केस का आधा संवेदनशील बनाते हैं, और दूसरा आधा असंवेदनशील। यह दोनों बग के वर्गों को पकड़ लेंगे। – Darron

+0

हमारे पास DEV और TEST पर अलग-अलग सर्वर कॉलेशन हैं। यह सुनिश्चित करता है कि हम हमेशा हमारे द्वारा बनाई गई किसी भी अस्थायी सारणी (उदा। एक स्पोक में) और किसी भी दिनांक स्वरूपण पर कॉललेट निर्दिष्ट करते हैं जो गलती से सर्वर सेटअप – Kristen

5

यूनिकोड के सभी वर्गों में ऊपरी और निचले-केस वर्णों के बीच एक जैविक मैपिंग नहीं है - या यहां तक ​​कि मामलों के दो सेट भी हैं।

उन क्षेत्रों में, "केस-असंवेदनशीलता" थोड़ा अर्थहीन है, और शायद भ्रामक है।

यह सब कुछ मैं अब के बारे में सोच सकता हूं; एएससीआईआई सेट में, जब तक कि आप फू और फू अलग नहीं होना चाहते हैं, मुझे बिंदु नहीं दिख रहा है।

+1

जानना उत्सुक है कि कितने लोग जानना चाहते हैं कि जैविक उद्देश्य क्या है? :-)। बुनियादी सेट सिद्धांत/संयोजन के बिना वे अंधेरे में विकिपीडिया के बिना बाहर होंगे? – Bill

1

केस असंवेदनशीलता एक देवता है जब आपके पास ऐसे डेवलपर्स हैं जो एसक्यूएल लिखते समय या विकास भाषाओं से आने पर किसी भी प्रकार के सम्मेलनों का पालन करने में विफल रहते हैं, जहां केस असंवेदनशीलता वीबी जैसे मानक है।

आम तौर पर बोलते हुए मुझे डेटाबेस से निपटना आसान लगता है जहां आईडी, आईडी और आईडी अलग-अलग फ़ील्ड नहीं हैं।

यातना के लिए व्यक्तिगत वरीयता के अलावा, मैं दृढ़ता से अनुशंसा करता हूं कि आप मामले की संवेदनशीलता के साथ बने रहें।

एकमात्र डेटाबेस जिस पर मैंने कभी काम किया था, केस सेंसिटीविटी ग्रेट प्लेेंस के लिए स्थापित किया गया था। मुझे याद है कि उनके स्कीमा नामों के हर एक आवरण को दर्दनाक था। मुझे हाल के संस्करणों के साथ काम करने का विशेषाधिकार नहीं मिला है।

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

7

मैं वास्तव में किसी भी अच्छे कारण के बारे में नहीं सोच सकता एसक्यूएल पहचानकर्ता केस संवेदनशील होना चाहिए। मैं एक खराब एक के बारे में सोच सकता हूं, यह एक MySQL देता है कि उनके टेबल नाम केस संवेदनशील क्यों हैं। प्रत्येक तालिका डिस्क पर एक फ़ाइल है, आपकी फाइल सिस्टम केस-संवेदी है और MySQL devs table_file = lc(table_name) पर भूल गए हैं। जब आप एक MySQL स्कीमा को केस-असंवेदनशील फाइल सिस्टम में ले जाते हैं तो यह मजेदार ढेर है।

मैं एक बड़े कारण के बारे में सोच सकता हूं कि उन्हें केस संवेदनशील क्यों नहीं होना चाहिए।

कुछ स्कीमा लेखक चालाक होने जा रहे हैं और निर्णय लेते हैं कि this_table स्पष्ट रूप से This_Table से कुछ अलग है और उन दो तालिकाओं (या कॉलम) को बनाते हैं। स्कीमा में उस बिंदु पर आप "यहां भी बग डाल सकते हैं।

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

SELECT this, that FROM Table; 
3

वहाँ अधिकांश भाषाओं, केस-संवेदी होते। यद्यपि यह चीजों को टाइप करने में आसान बनाता है, और इसी मामले के कई प्रकारों को केवल मामले के आधार पर अलग करता है।

व्यक्तिगत रूप से, (MyTable, mytable, mytable, mytable, mytable, mytable, mytable) के बीच, मैं कृपयाएक सार्वभौमिक संस्करण देखने के लिए चाहते हैं।

1

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

2

मुझे केस-सेंसिटीविटी पसंद है, अधिकतर क्योंकि मैं पर्ल में प्रोग्रामिंग (और किसी भी अन्य भाषा में भी) से उपयोग करता हूं। मुझे कॉलम के लिए अंडरस्कोर के साथ टेबल नामों और सभी निचले मामले के लिए स्टडीली कैप्स का उपयोग करना पसंद है।

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

1

मुझे यकीन है कि एसक्यूएल स्पेक को पहचानकर्ताओं के लिए केस फोल्डिंग (जो प्रभावी रूप से असंवेदनशीलता के समान है) की आवश्यकता है। PostgreSQL कम करने के लिए folds, ओरेकल ऊपरी भाग में folds।

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