MySQL: स्टीरियोटाइप्स को तोड़ना

हाल ही में, मैं अक्सर इस तथ्य के बारे में लोगों के विभिन्न तर्कों पर आना शुरू हुआ कि MySQL खराब है, यह बहुत बुरा है - क्योंकि ... लेकिन फिर विभिन्न MySQL सुविधाओं के विवरण हैं जो स्पष्ट रूप से प्रलेखित हैं, लेकिन उपयोगकर्ता बस उन्हें नहीं जानता है। कोई डेटाबेस के सत्यापन के बिना डेटा जोड़ता है और आश्चर्य करता है कि उन्हें गलत प्रारूप में क्यों सहेजा गया था, और किसी ने myIsam इंजन की सुविधाओं का एक गुच्छा वर्णित किया है, और इन आधारों पर निष्कर्ष निकाला है कि MySQL बेकार है - जिसका वास्तविक परियोजनाओं में उपयोग नहीं किया जा सकता है। सभी दस्तावेज़ों को पढ़ना असंभव है, और हाँ - मैं इस बात से पूरी तरह सहमत हूं, लेकिन मेरा विश्वास करो, हमारे पास अन्य अनिर्दिष्ट और कम दिलचस्प विशेषताओं का एक गुच्छा नहीं है। उदाहरण के लिए, छोटा शुरू करते हैं, यह साबित करते हैं कि NULL शून्य है।

NULL एक जटिल संरचना है, प्रत्येक डेटाबेस इसे अपने तरीके से व्याख्या करता है। MySQL में Oracle (जैसे NULL एक खाली स्ट्रिंग के बराबर है) में ऐसी कोई विकृतियाँ नहीं हैं, यहाँ सब कुछ बहुत ठंडा है। एक ओर, NULL शून्य है। यह साबित करना आसान है। आइए एक सरल तालिका null_equals_zero और इसे 4 कॉलम के साथ एक अद्वितीय कॉलम नंबर 2 के साथ भरें, जिसके द्वारा हम समूह null_equals_zero ।

 create table null_equals_zero(int_value int, group_value int ) engine = innodb; insert into null_equals_zero values (null, 1), (0, 2), (NULL, 3), (0, 4); select distinct int_value from null_equals_zero group by group_value; 

जैसा कि आप जानते हैं, यह क्वेरी हमें पहले कॉलम के अनूठे मूल्यों की ओर लौटाएगी, जैसा कि हम जानते हैं, दो: शून्य और पूर्ण

यह उदाहरण विवादास्पद स्थितियों में NULL के व्यवहार का केवल एक हिस्सा है, क्योंकि यह शून्य के बराबर है, लेकिन यह भी आसानी से साबित किया जा सकता है कि NULL एक से अधिक है। आइए दो कार्यों को देखें: least - जो सूचीबद्ध तर्कों से न्यूनतम मूल्य लौटाता है, और elt - जो पहले तर्क द्वारा निर्दिष्ट सूचकांक पर मूल्य लौटाता है। मुझे लगता है कि इस पोस्ट को पढ़ने वालों में से कोई भी नहीं है, उनके पास सवाल है कि वे कैसे काम करते हैं, लेकिन सिर्फ मामले में, प्रयोग की शुद्धता के लिए, हम 2 प्रश्नों को निष्पादित करेंगे:

 select least(1, null) cmp_res; +---------+ | cmp_res | +---------+ | NULL | +---------+ 1 row in set (0.00 sec) select elt(null, '   NULL') null_index_field; +------------------+ | null_index_field | +------------------+ | NULL | +------------------+ 1 row in set (0.00 sec) 

जब हम देखते हैं कि सब कुछ योजना के अनुसार हो रहा है, तो NULL एक तरफ अतुलनीय है, और NULL इंडेक्स द्वारा कोई तत्व नहीं हैं, लेकिन आइए यह पता लगाने की कोशिश करें कि इन कार्यों का सुपरपोज़िशन किसके बराबर है?

 select elt(least(1, null), '1 < null') null_is_to_big; 

अब गणित करते हैं, मुझे लगता है कि पहली कक्षा सबसे ज्यादा है। और इसलिए सवाल यह है कि नंबर 0. किस संकेत पर है। जवाब देने के लिए समय निकालें, आपको पहले ही पता चल गया था कि MySQL डेवलपर्स भयानक ट्रोल हैं। आइए इसे बेहतर तरीके से जांचें। और ऐसा है। एक तालिका बनाएं और उसमें शून्य के करीब दो मान डालें - सकारात्मक और नकारात्मक।

 create table signed_zero (float_value float); insert into signed_zero(float_value) values (-0.1), (0.1); select group_concat(round(float_value) separator '   ') signed_zero from signed_zero group by round(float_value); 

ठीक है, चलो गणित से पचते हैं और असंभव वस्तुओं की ओर बढ़ते हैं। यह पता चलता है कि MySQL में ऑब्जेक्ट्स हैं जिन्हें बनाया नहीं जा सकता (उद्धरण के प्रेमियों के लिए समर्पित)। आइए पहले से ही एक टेबल बनाने की कोशिश करें जिसे पहले से ही कहा जाता है।
चलो निर्देशिका के साथ शुरू करते हैं (एक विदेशी कुंजी के बिना एक तालिका)।

 create table `dictionary_one` (`dict_id` int(10) primary key) engine = innodb; create table `already_exists`( `pk_id` int(10) primary key, `ref_dict_one_id` int(10), constraint `Already_exists_ibfk_1` foreign key(`ref_dict_one_id`) references `dictionary_one`(`dict_id`) ); 

ऐसा लगता है कि सबकुछ वैसा ही हो रहा है जैसा होना चाहिए। अब - एक और तालिका संदर्भित एक और कॉलम जोड़ें।

 create table `dictionary_two` (`dict_id` int(10) primary key) engine = innodb; alter table `already_exists` add column `ref_dict_two_id` int(10), add foreign key `Already_exists_ibfk_2`(`ref_dict_two_id`) references `dictionary_two`(`dict_id`); 

कोई सिंटैक्स त्रुटियां नहीं हैं, सब कुछ सही ढंग से किया जाता है

मुझे याद है कि सभी मंचों में आईपीवी 6 की शुरुआत के साथ ही सवाल गड़बड़ा रहा था। IP पते को संग्रहीत करने के लिए किस प्रकार का उपयोग करें? अलग-अलग धारणाएं DECIMAL(39) 2bigint(20) DECIMAL(39) , 2bigint(20) , binary , 2bigint(20) । लेकिन हमें समझौते की आवश्यकता क्यों है? आखिरकार, हर कोई जानता है कि bigint केवल 20 वर्णों तक सीमित नहीं है। आपको कैसे पता नहीं चला? वैसे यह साबित करना भी आसान है।

 create table new_unlimited_table as select cast(substr(repeat(' ', 21848), 10) as signed integer) new_bigint_field; select column_type from information_schema.columns where table_name = 'new_unlimited_table' and table_schema = database() and column_name = 'new_bigint_field'; 

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

 create table data_ordering (varchar_value varchar(10)); insert into data_ordering values (''), ('string'); select * from data_ordering where 'string' regexp varchar_value; +---------------+ | varchar_value | +---------------+ | string | +---------------+ 1 row in set (0.00 sec) 

जबकि सब कुछ सच है और धोखाधड़ी के बिना, वास्तव में केवल एक पंक्ति हमारी स्थिति को संतुष्ट करती है। अब उल्टे क्रम में।

 delete from data_ordering; insert into data_ordering values ('string'), (''); select * from data_ordering where 'string' regexp varchar_value; 

समान पंक्तियाँ - समान अनुरोध


तो मैं यह सब किस लिए कर रहा हूं? मेरा विश्वास करो, डेवलपर्स से चाल कहीं से भी उम्मीद की जा सकती है, और यह तथ्य कि MySQL का व्यवहार प्रलेखन से मेल खाता है, बहुत अच्छा है, जब विपरीत सच है तो बहुत बुरा। नया साल मुबारक हो!