2018 में MySQL:8.0 और अन्य टिप्पणियों में क्या है

अधिकांश के साथ, यदि 2018 हमारे पीछे नहीं है (इस पर निर्भर करता है कि आप इस पोस्ट को कब पढ़ रहे हैं), इसमें कोई संदेह नहीं है कि यह ओपन-सोर्स SQL ​​डेटाबेस के लिए एक शानदार वर्ष था।

PostgreSQL 11 और MySQL 8 दोनों को रिलीज़ किया गया, दोनों समुदायों को 'बात करने . के लिए बहुत कुछ प्रदान किया गया '। सच कहा जाए, तो दोनों विक्रेताओं ने अपनी-अपनी रिलीज में कई महत्वपूर्ण बदलाव और परिवर्धन पेश किए हैं और उनकी प्रशंसा और प्रशंसा के पात्र हैं।

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

तो MySQL 8 में क्या है कि संस्करण 5.7 में नहीं है? क्या सुधार हैं? खैर, बहुत सारे हैं। वास्तव में, केवल एक ब्लॉग पोस्ट में कवर करने के लिए बहुत कुछ है।

मैंने हाल ही में अपने वर्तमान Linux शिक्षण/विकास परिवेश में संस्करण 8 में अपग्रेड किया है, इसलिए मैंने उनमें से कुछ को इंगित करने के लिए अपना हाथ आजमाने के बारे में सोचा।

मैं आपको आपके 'पसंदीदा . पर गहन चर्चा की गारंटी नहीं दे सकता ' नई सुविधाओं)। दूसरी ओर, मैं उन लोगों से मिलूंगा जिन्होंने मेरा ध्यान व्यक्तिगत रुचि के माध्यम से या संस्करण 8 पर पूरे वर्ष में प्रकाशित कई शानदार ब्लॉग पोस्ट के माध्यम से खींचा है।

MySQL बेहतर और बेहतर होता जा रहा है...संस्करण 8 में शानदार सुधार!

भूमिकाएं

भूमिकाओं के साथ, डीबीए अतिरेक को कम कर सकता है, जहां कई उपयोगकर्ता समान विशेषाधिकार या विशेषाधिकारों के समूह को साझा करेंगे।

भूमिकाएं SQL मानक का हिस्सा हैं।

वांछित/आवश्यक विशेषाधिकार (विशेषाधिकारों) के साथ एक विशिष्ट भूमिका बनाने के बाद, आप उपयोगकर्ताओं को उस विशेष भूमिका को GRANT कमांड या इसी तरह, 'टेकथ अवे के माध्यम से असाइन कर सकते हैं। ' रिवोक के साथ।

भूमिकाएँ अनेक लाभों के साथ आती हैं और जीवन को थोड़ा आसान बनाने के लिए, उन पर नज़र रखने में आपकी मदद करने के लिए कुछ तालिकाएँ हैं:

• mysql.role_edges - यहां आपको वे भूमिकाएं और वे उपयोगकर्ता मिलते हैं जिन्हें उन्हें सौंपा गया है।

  mysql> DESC mysql.role_edges;
  +-------------------+---------------+------+-----+---------+-------+
  | Field             | Type          | Null | Key | Default | Extra |
  +-------------------+---------------+------+-----+---------+-------+
  | FROM_HOST         | char(60)      | NO   | PRI |         |       |
  | FROM_USER         | char(32)      | NO   | PRI |         |       |
  | TO_HOST           | char(60)      | NO   | PRI |         |       |
  | TO_USER           | char(32)      | NO   | PRI |         |       |
  | WITH_ADMIN_OPTION | enum('N','Y') | NO   |     | N       |       |
  +-------------------+---------------+------+-----+---------+-------+
  5 rows in set (0.01 sec)

• mysql.default_roles - किसी भी डिफ़ॉल्ट भूमिका और असाइन किए गए उपयोगकर्ताओं को संग्रहीत करता है।

  mysql> DESC mysql.default_roles;
  +-------------------+----------+------+-----+---------+-------+
  | Field             | Type     | Null | Key | Default | Extra |
  +-------------------+----------+------+-----+---------+-------+
  | HOST              | char(60) | NO   | PRI |         |       |
  | USER              | char(32) | NO   | PRI |         |       |
  | DEFAULT_ROLE_HOST | char(60) | NO   | PRI | %       |       |
  | DEFAULT_ROLE_USER | char(32) | NO   | PRI |         |       |
  +-------------------+----------+------+-----+---------+-------+
  4 rows in set (0.00 sec)

दोनों तालिकाओं का संयोजन (एसक्यूएल जॉइन अर्थ में नहीं) अनिवार्य रूप से 'केंद्रीकृत स्थान प्रदान करता है ' जहां आप कर सकते हैं:अपने सभी लागू उपयोगकर्ता-भूमिका विशेषाधिकार संबंधों और असाइनमेंट को जान सकते हैं, निगरानी कर सकते हैं और उनका आकलन कर सकते हैं।

संभवतः सबसे सरल उदाहरण भूमिका उपयोग परिदृश्य होगा:

आपके कई उपयोगकर्ता हैं जिन्हें 'केवल पढ़ने के लिए पहुंच . की आवश्यकता है ' एक विशिष्ट तालिका पर, इसलिए, कम से कम चयन विशेषाधिकार की आवश्यकता होती है। प्रत्येक उपयोगकर्ता को व्यक्तिगत रूप से इसे (चयन) देने के बजाय, आप उस विशेषाधिकार वाली भूमिका स्थापित कर सकते हैं (बना सकते हैं), फिर उस भूमिका को उन उपयोगकर्ताओं को सौंप सकते हैं।

लेकिन, भूमिकाएं एक छोटे से 'पकड़ . के साथ आती हैं '। एक बार उपयोगकर्ता को बनाने और असाइन करने के बाद, प्राप्त करने वाले उपयोगकर्ता के पास लॉगिन पर प्रमाणीकरण के दौरान एक सक्रिय डिफ़ॉल्ट भूमिका सेट होनी चाहिए।

भूमिकाओं और उपयोगकर्ताओं के विषय पर, मुझे लगता है कि MySQL 8 में लागू किए गए परिवर्तन का उल्लेख करना महत्वपूर्ण है, जो कि वैलिडेट_पासवर्ड घटक से संबंधित है, जो कि संस्करण 5.7 में उपयोग किए गए वैलिडेट_पासवर्ड प्लगइन का एक प्रकार है।

यह घटक विभिन्न विशिष्ट 'श्रेणियां प्रदान करता है ' पासवर्ड की जाँच:कम, मध्यम (डिफ़ॉल्ट), और मजबूत। प्रत्येक स्तर की सत्यापन विशिष्टताओं के बारे में पूरी जानकारी के लिए मान्य_पासवर्ड घटक दस्तावेज़ीकरण पर जाएं।

एसक्यूएल के साथ नोएसक्यूएल मिंगल - द डॉक्यूमेंट स्टोर

2016 की शुरुआत में MongoDB में एक क्षणभंगुर रुचि के बावजूद, मैं अभी भी इस सुविधा के बारे में सीख रहा हूं। आज तक, मेरी रुचि, अध्ययन और सीखने को पूरी तरह से 'एसक्यूएल' पर केंद्रित किया गया है। हालांकि, मुझे पता है (वेब ​​पर बहुत अधिक पढ़ने के माध्यम से) कि बहुत से लोग इस प्रकार की संरचना (दस्तावेज़-उन्मुख) के बारे में उत्साहित हैं जो 'रिलेशनल एसक्यूएल' के साथ जुड़े हुए हैं जो अब MySQL 8 दस्तावेज़ स्टोर में उपलब्ध है।

दस्तावेज़ स्टोर का उपयोग करते समय नीचे कई लाभ उपलब्ध हैं। सुनिश्चित करें और अपने पसंदीदा का उल्लेख करें जो मैंने टिप्पणी अनुभाग में याद किया होगा:

• JSON डेटा प्रकार MySQL संस्करण 5.7.8 के बाद से समर्थित है, अभी तक संस्करण 8 ने JSON के साथ काम करने के लिए महत्वपूर्ण एन्हांसमेंट पेश किए हैं। 'आशुलिपि . के साथ नए JSON विशिष्ट कार्य ' ऑपरेटर जिनका उपयोग एकाधिक फ़ंक्शन कॉल के स्थान पर किया जा सकता है - समान परिणाम/आउटपुट के साथ।
• शायद सबसे महत्वपूर्ण लाभों में से एक यह है कि अब आपको कई डेटाबेस समाधानों को लागू करने और उनके साथ काम करने की आवश्यकता नहीं है क्योंकि दस्तावेज़ स्टोर में NoSQL, SQL, या दोनों का संयोजन समर्थित है।
• एक "देवएपीआई", नोएसक्यूएल डेटा संदर्भ (संग्रह और दस्तावेज) के भीतर निर्बाध कार्यप्रवाह क्षमताएं प्रदान करता है। (अधिक जानकारी के लिए आधिकारिक DevAPI उपयोगकर्ता मार्गदर्शिका दस्तावेज़ देखें)।
• पायथन, एसक्यूएल, या जावास्क्रिप्ट को 'शेल' भाषा के रूप में उपयोग करते हुए शक्तिशाली कमांड-लाइन सत्र।
• एसिड अनुपालन।
• किसी संबंधपरक मॉडल की तरह किसी स्कीमा को परिभाषित किए बिना अपने डेटा को तुरंत एक्सप्लोर करें और खोजें।

कॉमन टेबल एक्सप्रेशन (CTE या WITH क्लॉज)

सीटीई के बारे में आप और क्या कह सकते हैं? ये चीजें गेम-चेंजर हैं! शुरुआत के लिए, सामान्य तालिका अभिव्यक्ति वास्तव में क्या है?

विकिपीडिया से:

"एक सामान्य तालिका अभिव्यक्ति, या सीटीई, (एसक्यूएल में) एक अस्थायी नामित परिणाम सेट है, जो एक साधारण क्वेरी से प्राप्त होता है और एक चयन, INSERT, अद्यतन, या हटाएं कथन के निष्पादन दायरे में परिभाषित होता है।"

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

मेरे पास इस विवरण और डेटा के साथ एक साधारण नाम तालिका है:

mysql> DESC name;
+--------+-------------+------+-----+---------+-------+
| Field  | Type        | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| f_name | varchar(20) | YES  |     | NULL    |       |
| l_name | varchar(20) | YES  |     | NULL    |       |
+--------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name     |
+--------+------------+
| Jim    | Dandy      |
| Johhny | Applesauce |
| Ashley | Zerro      |
| Ashton | Zerra      |
| Ashmon | Zerro      |
+--------+------------+
5 rows in set (0.00 sec)

आइए जानें कि कितने अंतिम नाम 'Z' से शुरू होते हैं:

mysql> SELECT *
    -> FROM name
    -> WHERE l_name LIKE 'Z%';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro  |
| Ashton | Zerra  |
| Ashmon | Zerro  |
+--------+--------+
3 rows in set (0.00 sec)

काफी आसान।

हालांकि, WITH क्लॉज का उपयोग करके, आप 'एक्सेस . कर सकते हैं ' यह वही क्वेरी परिणाम सेट (जिसे व्युत्पन्न तालिका के रूप में माना जा सकता है) और बाद में उसी कथन के भीतर इसका संदर्भ लें - या 'स्कोप ':

 WITH last_Z AS (
           SELECT *
           FROM name
           WHERE l_name LIKE 'Z%')
   SELECT * FROM last_Z;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro  |
| Ashton | Zerra  |
| Ashmon | Zerro  |
+--------+--------+
3 rows in set (0.00 sec)

मैं मूल रूप से क्वेरी को एक नाम निर्दिष्ट करता हूं, इसे कोष्ठक में लपेटता है। फिर बस उस डेटा का चयन करें जो मुझे चाहिए जो अब last_Z CTE है।

last_Z CTE एक संपूर्ण परिणाम सेट प्रदान करता है, ताकि आप इसे उसी कथन में और भी आगे फ़िल्टर कर सकें:

WITH last_Z AS ( 
           SELECT *
           FROM name
           WHERE l_name LIKE 'Z%')
   SELECT f_name, l_name FROM last_Z WHERE l_name LIKE '%a';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra  |
+--------+--------+
1 row in set (0.00 sec)

कुछ अधिक शक्तिशाली विशेषताएं हैं 'चेनिंग ' कई सीटीई एक साथ और सीटीई के भीतर अन्य सीटीई के संदर्भ में।

आपको एक विचार देने के लिए यहां एक उदाहरण दिया गया है (हालांकि इतना उपयोगी नहीं है):

WITH last_Z AS ( 
           SELECT *
           FROM name
           WHERE l_name LIKE 'Z%'),
        best_friend AS (
           SELECT f_name, l_name
           FROM last_Z
           WHERE l_name LIKE '%a')
   SELECT * from best_friend;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra  |
+--------+--------+
1 row in set (0.00 sec)

उपरोक्त क्वेरी में, आप देख सकते हैं कि मैंने last_Z CTE को best_friend CTE से अल्पविराम से अलग किया और फिर AS कीवर्ड के बाद उस क्वेरी को कोष्ठक में लपेट दिया।

ध्यान दें कि फिर मैं best_friend CTE को अनिवार्य रूप से परिभाषित करने के लिए last_Z CTE को संदर्भित (और उपयोग) करने में सक्षम हूं।

यहाँ कुछ कारण दिए गए हैं कि क्यों CTE का संस्करण 8 में इतना महत्वपूर्ण सुधार है:

• अन्य SQL विक्रेताओं ने CTE का समर्थन किया है (उनके व्यक्तिगत पारिस्थितिकी तंत्र के पुराने संस्करणों के बाद से कई) और अब MySQL 8 ने इस क्षेत्र में अंतर को बंद कर दिया है।
• एक मानक SQL समावेशन।
• कुछ मामलों में (जहां उपयुक्त हो), अस्थायी तालिकाओं, दृश्यों, व्युत्पन्न तालिकाओं (या इनलाइन दृश्यों) और कुछ उपश्रेणियों की तुलना में सीटीई बेहतर विकल्प हैं।
• CTE's एक 'ऑन-द-फ्लाई . प्रदान कर सकते हैं ' गणना परिणाम सेट जिसके खिलाफ आप क्वेरी कर सकते हैं।
• एक सीटीई खुद को संदर्भित कर सकता है - एक पुनरावर्ती सीटीई के रूप में जाना जाता है (यहां प्रदर्शित नहीं किया गया)।
• CTE अन्य CTE का नाम और उपयोग कर सकते हैं

विंडो फ़ंक्शन

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

मेरे पास यह दृश्य है जो एक काल्पनिक पाइप डेटा परिणाम सेट प्रदान करता है (कुछ मैं कुछ हद तक समझता हूं):

mysql> SELECT * FROM pipe_vw;
+---------+-------------+-----------+-------+-------------+------------+----------------+
| pipe_id | pipe_name   | joint_num | heat  | pipe_length | has_degree | wall_thickness |
+---------+-------------+-----------+-------+-------------+------------+----------------+
|     181 | Joint-278   | 39393A    | 9111  |       17.40 |          1 |          0.393 |
|     182 | Joint-8819  | 19393Y    | 9011  |       16.60 |          0 |          0.427 |
|     183 | Joint-9844  | 39393V    | 8171  |       10.40 |          0 |          0.393 |
|     184 | Joint-2528  | 34493U    | 9100  |       11.50 |          1 |          0.427 |
|     185 | Joint-889   | 18393z    | 9159  |       13.00 |          0 |          0.893 |
|     186 | Joint-98434 | 19293Q    | 8174  |        9.13 |          0 |          0.893 |
|     187 | Joint-78344 | 17QTT     | 179   |       44.40 |          1 |          0.893 |
|     188 | Joint-171C  | 34493U    | 17122 |        9.45 |          1 |          0.893 |
|     189 | Joint-68444 | 17297Q    | 6114  |       11.34 |          0 |          0.893 |
|     190 | Joint-4841R | 19395Q    | 5144  |       25.55 |          0 |          0.115 |
|     191 | Joint-1224C | 34493U    | 8575B |       15.22 |          1 |          0.893 |
|     192 | Joint-2138  | 34493C    | 91    |       13.55 |          1 |          0.893 |
|     193 | Joint-122B  | 34493U    | 9100B |        7.78 |          1 |          0.893 |
+---------+-------------+-----------+-------+-------------+------------+----------------+
13 rows in set (0.00 sec)

कल्पना कीजिए, मुझे प्रत्येक व्यक्तिगत पाइप की लंबाई के आधार पर किसी प्रकार की पंक्ति रैंकिंग में प्रस्तुत पाइप संपत्ति रिकॉर्ड की आवश्यकता है। (उदाहरण के लिए, सबसे लंबी लंबाई को नंबर 1 स्थिति 'लेबल' किया जाता है, दूसरी सबसे लंबी लंबाई 'लेबल' स्थिति 2, आदि...)

दस्तावेज़ में रैंक () विंडो फ़ंक्शन विवरण के आधार पर:

"अंतराल के साथ, अपने विभाजन के भीतर वर्तमान पंक्ति की रैंक देता है। साथियों को संबंध माना जाता है और समान रैंक प्राप्त करते हैं। यह फ़ंक्शन सहकर्मी समूहों को लगातार रैंक नहीं देता है यदि एक से अधिक आकार के समूह मौजूद हैं; परिणाम गैर-क्रमांक रैंक संख्या है ।"

ऐसा लगता है कि यह इस आवश्यकता के लिए उपयुक्त है।

mysql> SELECT pipe_name, pipe_length,
    -> RANK() OVER(ORDER BY pipe_length DESC) AS long_to_short
    -> FROM pipe_vw;
+-------------+-------------+---------------+
| pipe_name   | pipe_length | long_to_short |
+-------------+-------------+---------------+
| Joint-78344 |       44.40 |             1 |
| Joint-4841R |       25.55 |             2 |
| Joint-278   |       17.40 |             3 |
| Joint-8819  |       16.60 |             4 |
| Joint-1224C |       15.22 |             5 |
| Joint-2138  |       13.55 |             6 |
| Joint-889   |       13.00 |             7 |
| Joint-2528  |       11.50 |             8 |
| Joint-68444 |       11.34 |             9 |
| Joint-9844  |       10.40 |            10 |
| Joint-171C  |        9.45 |            11 |
| Joint-98434 |        9.13 |            12 |
| Joint-122B  |        7.78 |            13 |
+-------------+-------------+---------------+
13 rows in set (0.01 sec)

अगले परिदृश्य में, मैं पिछले उदाहरण पर सबसे लंबी से छोटी लंबाई के रिकॉर्ड की रैंकिंग करके और भी आगे निर्माण करना चाहता हूं, लेकिन, अलग-अलग Wall_thickness मानों के प्रत्येक व्यक्तिगत समूह के अनुसार।

शायद नीचे दी गई क्वेरी और परिणाम बेहतर व्याख्या करेंगे जहां मेरा गद्य नहीं हो सकता है:

mysql> SELECT pipe_name, pipe_length, wall_thickness,
    -> RANK() OVER(PARTITION BY wall_thickness ORDER BY pipe_length DESC) AS long_to_short
    -> FROM pipe_vw;
+-------------+-------------+----------------+---------------+
| pipe_name   | pipe_length | wall_thickness | long_to_short |
+-------------+-------------+----------------+---------------+
| Joint-4841R |       25.55 |          0.115 |             1 |
| Joint-278   |       17.40 |          0.393 |             1 |
| Joint-9844  |       10.40 |          0.393 |             2 |
| Joint-8819  |       16.60 |          0.427 |             1 |
| Joint-2528  |       11.50 |          0.427 |             2 |
| Joint-78344 |       44.40 |          0.893 |             1 |
| Joint-1224C |       15.22 |          0.893 |             2 |
| Joint-2138  |       13.55 |          0.893 |             3 |
| Joint-889   |       13.00 |          0.893 |             4 |
| Joint-68444 |       11.34 |          0.893 |             5 |
| Joint-171C  |        9.45 |          0.893 |             6 |
| Joint-98434 |        9.13 |          0.893 |             7 |
| Joint-122B  |        7.78 |          0.893 |             8 |
+-------------+-------------+----------------+---------------+
13 rows in set (0.00 sec)

यह क्वेरी वॉल_थिकनेस कॉलम पर पार्टिशन बाय क्लॉज का उपयोग करती है क्योंकि हम रैंकिंग चाहते हैं (जो ORDER BY pipe_length DESC प्रदान करता है) हालांकि, हमें अलग-अलग Wall_thickness समूहों के संदर्भ में इसकी आवश्यकता है।

जब आप किसी भिन्न वॉल_थिकनेस कॉलम मान से मिलते हैं (या बदलते हैं) तो प्रत्येक long_to_short कॉलम रैंकिंग 1 पर रीसेट हो जाती है।

आइए एक ही समूह के परिणामों पर ध्यान दें।

Wall_thickness मान 0.893 के साथ रिकॉर्ड को लक्षित करते हुए, pipe_length 44.40 वाली पंक्ति में 1 की एक समान long_to_short 'रैंकिंग' है (यह सबसे लंबी है), जबकि pipe_length 7.78 वाली पंक्ति में एक समान long_to_short 'रैंकिंग' 8 (सबसे छोटी) है। Wall_thickness मानों का विशिष्ट समूह (0.893)।

विंडो फ़ंक्शंस काफी शक्तिशाली हैं और उनके पूरे दायरे और चौड़ाई को संभवतः अकेले एक सेक्शन में शामिल नहीं किया जा सकता है। सुनिश्चित करें और वर्तमान में उपलब्ध उन पर अधिक जानकारी के लिए MySQL 8 दस्तावेज़ीकरण में समर्थित विंडो फ़ंक्शंस पर जाएं।

बेहतर स्थानिक सहायता और क्षमताएं

यह MySQL 8 में शामिल सुविधाओं का एक जबरदस्त सेट है। पिछले संस्करणों के समर्थन, या इसके अभाव में, अन्य विक्रेता कार्यान्वयन (ओं) की तुलना नहीं की जा सकती है (PostgreSQL के लिए PostGIS सोचें)।

पिछले 10 से अधिक वर्षों से, मैंने पाइपलाइन सर्वेयर के रूप में काम किया है, जीपीएस और संपत्ति डेटा एकत्र किया है, इसलिए परिवर्तनों का यह समूह निश्चित रूप से मेरा ध्यान आकर्षित करता है।

स्थानिक डेटा विशेषज्ञता अपने आप में एक व्यापक विषय है और आश्वस्त रहें, मैं इस पर एक विशेषज्ञ से बहुत दूर हूं। हालांकि, मैं संस्करण 5.7 और 8 के बीच महत्वपूर्ण परिवर्तनों को संक्षेप में प्रस्तुत करना चाहता हूं और उन्हें स्पष्ट और संक्षिप्त तरीके से बताना चाहता हूं।

आइए इस खंड के प्रयोजनों के लिए 2 प्रमुख शब्दों (और अवधारणाओं) से खुद को परिचित करें।

1. स्थानिक संदर्भ प्रणाली या एसआरएस - यहां विकिपीडिया से आंशिक परिभाषा दी गई है:

   "एक स्थानिक संदर्भ प्रणाली (एसआरएस) या समन्वय संदर्भ प्रणाली (सीआरएस) एक समन्वय-आधारित स्थानीय, क्षेत्रीय या वैश्विक प्रणाली है जिसका उपयोग भौगोलिक संस्थाओं का पता लगाने के लिए किया जाता है। एक स्थानिक संदर्भ प्रणाली एक विशिष्ट मानचित्र प्रक्षेपण को परिभाषित करती है, साथ ही विभिन्न स्थानिक संदर्भों के बीच परिवर्तन भी करती है। सिस्टम।"

2. स्थानिक संदर्भ प्रणाली पहचानकर्ता या SRID - साथ ही, विकिपीडिया में SRID को इस प्रकार परिभाषित किया गया है:

   "एक स्थानिक संदर्भ प्रणाली पहचानकर्ता (SRID) एक अद्वितीय मूल्य है जिसका उपयोग प्रक्षेपित, अप्रकाशित और स्थानीय स्थानिक समन्वय प्रणाली परिभाषाओं को स्पष्ट रूप से पहचानने के लिए किया जाता है। ये समन्वय प्रणाली सभी GIS अनुप्रयोगों का दिल बनाती हैं।"

MySQL कई स्थानिक डेटा प्रकारों का समर्थन करता है। अधिक सामान्य में से एक एक बिंदु है। यदि आप अपने पसंदीदा रेस्तरां में नेविगेट करने के लिए अपने GPS का उपयोग करते हैं, तो वह स्थान मानचित्र पर एक बिंदु है।

MySQL 5.7 प्रत्येक 'स्थानिक वस्तु का बहुत अधिक व्यवहार करता है ' 0 का SRID होने के नाते, जो संगणना के लिए महत्वपूर्ण है। उन गणनाओं की गणना कार्टेशियन प्रकार की समन्वय प्रणाली में की जाती है। हालाँकि, हम सभी जानते हैं कि हमारा ग्लोब एक गोला है और समतल से बहुत दूर है। इसलिए, संस्करण 8 में, आपके पास गणना में इसे सपाट या गोलाकार मानने की क्षमता है।

उन दो शर्तों पर वापस जाएं, जिन्हें हमने पहले परिभाषित किया था।

भले ही 0 MySQL संस्करण 8 में डिफ़ॉल्ट SRID है, कई (लगभग 5,000+) अन्य SRID समर्थित हैं।

लेकिन यह महत्वपूर्ण क्यों है?

ब्लॉग पोस्ट के माध्यम से यह शानदार व्याख्या, MySQL 8.0 में स्थानिक संदर्भ प्रणाली, इसे अच्छी तरह से प्रस्तुत करती है:

"डिफ़ॉल्ट रूप से, यदि हम SRID निर्दिष्ट नहीं करते हैं, तो MySQL SRID 0 में ज्यामिति बनाएगा। SRID 0 MySQL की एक अमूर्त, इकाई रहित, अनंत, केटियन विमान की धारणा है। जबकि अन्य सभी SRS कुछ सतह को संदर्भित करते हैं और इकाइयों को परिभाषित करते हैं। कुल्हाड़ियों, SRID 0 नहीं करता है।"

अनिवार्य रूप से, SRID के SRID 0 के अलावा . के साथ गणना करते समय , तब हमारी पृथ्वी का आकार चलन में आता है, माना जाता है, और उन गणनाओं को प्रभावित करता है। यह किसी भी सार्थक/सटीक गणना के लिए महत्वपूर्ण है। गहराई से विस्तार और बेहतर एक्सट्रपलेशन के लिए, MySQL 8 में भूगोल को कवर करने वाली यह ब्लॉग पोस्ट देखें।

मैं एसआरएस पर स्पष्टता के लिए MySQL सर्वर टीम ब्लॉग पोस्ट, MySQL 8.0 में भौगोलिक स्थानिक संदर्भ प्रणाली की भी अत्यधिक अनुशंसा करता हूं। सुनिश्चित करें और इसे पढ़ें!

अंत में, संस्करण 5.7 से 8 तक स्थानिक डेटा अपग्रेड संबंधी चिंताओं के लिए, अधिक जानकारी के लिए यहां सूचीबद्ध कुछ असंगत परिवर्तनों पर जाएं।

अन्य उल्लेखनीय अवलोकन

नीचे अन्य रिलीज़ एन्हांसमेंट हैं जिन्हें मुझे स्वीकार करना चाहिए, हालांकि वे इस ब्लॉग पोस्ट में गहराई से शामिल नहीं हैं:

• utf8mb4 अब डिफ़ॉल्ट वर्ण सेट है (पहले लैटिन 1) - उनके लिए बेहतर समर्थन के लिए कुछ भाषाओं के अलावा इमोजी भी होने चाहिए...
• लेन-देन संबंधी डेटा शब्दकोश - MySQL मेटाडेटा अब InnoDB तालिकाओं में रखा गया है।
• अदृश्य सूचकांक - अनुकूलक के लिए एक सूचकांक की दृश्यता निर्धारित करें, अंततः यह निर्धारित करें कि क्या इसे (सूचकांक) जोड़ना या हटाना एक अच्छी या बुरी चीज है। किसी मौजूदा बड़ी तालिका में अनुक्रमणिका जोड़ना 'महंगा . हो सकता है ' लॉकिंग और संसाधनों के संदर्भ में।
• अवरोही अनुक्रमणिका - अवरोही क्रम में संग्रहीत अनुक्रमित मानों पर बेहतर प्रदर्शन।
• तत्काल कॉलम जोड़ें - स्कीमा परिवर्तनों के लिए, ALGORITHM=INSTANT को ALTER TABLE स्टेटमेंट में निर्दिष्ट करें और (यदि ऑपरेशन के लिए संभव हो) मेटाडेटा लॉक से बचें। (अधिक जानकारी के लिए, MySQL सर्वर टीम द्वारा इस महान पोस्ट को देखें, और आधिकारिक डॉक्स से वैकल्पिक तालिका अनुभाग देखें।)

बोनस अनुभाग:कुछ ऐसा जो मुझे देखने की उम्मीद थी...

चेक बाधाओं ने अभी तक MySQL उत्पाद में प्रवेश नहीं किया है।

पिछले MySQL संस्करणों की तरह, आपके CREATE TABLE कमांड में चेक बाधा सिंटैक्स की अनुमति है लेकिन इसे अनदेखा कर दिया जाता है। मेरी जानकारी के लिए, अधिकांश अन्य SQL विक्रेता चेक बाधाओं का समर्थन करते हैं। आओ MySQL पार्टी में शामिल हों!

MySQL ने उल्लेखनीय रूप से 'बढ़ाया ' संस्करण 8 में इसकी पेशकश। मजबूत स्थानिक क्षमताओं, सुविधाजनक उपयोगकर्ता प्रबंधन भूमिका विकल्प, 'हाइब्रिड' एसक्यूएल/नोएसक्यूएल डेटा समाधान, और कई अतिरिक्त सुधारों के बीच विश्लेषणात्मक कार्यों का समर्थन, वास्तव में उल्लेखनीय है।

मेरी राय में, संस्करण 8 के साथ, MySQL लगातार बढ़ते, प्रतिस्पर्धी ओपन-सोर्स SQL ​​पारिस्थितिकी तंत्र में एक ठोस विकल्प प्रदान करना जारी रखता है, जो प्रासंगिक और सुविधा संपन्न समाधानों से भरा है।

पढ़ने के लिए धन्यवाद।