अधिकांश जीआईएस पैकेजों को संख्यात्मक आईडी की आवश्यकता क्यों होती है?


11

यह एक सरल अभी तक संभवतः विवादास्पद प्रश्न है: अधिकांश (यदि सभी नहीं) जीआईएस पैकेजों की आवश्यकता क्यों है कि एक निर्धारित परत में एक अद्वितीय नहीं अशक्त संख्यात्मक पहचानकर्ता है?

एक प्राकृतिक एक के बजाय इस तरह के सरोगेट कुंजी की आवश्यकता क्यों है?

उदाहरण:

  • ArcGIS OBJECTID (या एक GlobalID) को लागू करता है

  • QGIS परतों को लोड नहीं करता है जब उनके पास संख्यात्मक आईडी नहीं होती है।


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

+1 अच्छा प्रश्न, मुझे नहीं लगता कि NoSQL को संख्यात्मक कुंजी की आवश्यकता है।
किर्क कुएकेन्डल


@ एक छोटा सा टुकड़ा है (और आप पहले से ही उस लिंक को पोस्ट कर चुके हैं)।
whuber

जवाबों:


6

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

ESRI वास्तव में SDE दुनिया में 'GLOBALID' का समर्थन करता है जो एक GUID फ़ील्ड है, इसलिए यह 32char फ़ील्ड है लेकिन फिर भी प्रदर्शन को बढ़ाने के लिए अनुक्रमित है।


3
संख्यात्मक आईडी के दक्षता लाभ के लिए यह एक अच्छा स्पष्टीकरण है। लेकिन मुझे लगता है कि @George इससे कहीं अधिक गहराई से जांच कर रहा है। तकनीकी रूप से, आरडीबीएमएस को अपने पहचानकर्ताओं को संख्यात्मक होने की आवश्यकता नहीं है, इसलिए जीआईएस को क्यों चाहिए?
व्हिबर

1
यहाँ समस्या पूर्णता नहीं है। एक अशक्त अद्वितीय कुंजी यह नहीं करेगी। लेकिन यह संख्यात्मक क्यों होना चाहिए? एक बार जब मैंने सुना या पढ़ा है कि इसे संख्यात्मक होना चाहिए क्योंकि यह प्रतिपादन को नियंत्रित करने के लिए उस कुंजी का उपयोग करता है ... ESRI से हमारी दुनिया की मॉडलिंग में था?
जॉर्ज सिल्वा

2
क्योंकि जीआईएस एक आरडीबीएमएस नहीं है, हालांकि यह एक का उपयोग कर सकता है। एक जीआईएस में आमतौर पर कुछ नियम और धारणाएं होंगी, जैसे कि यह धारणा कि प्राथमिक कुंजी एक अनुक्रमित पूर्णांक या GUID होगी, प्रदर्शन और कोडिंग पवित्रता के लिए।
ब्लाह

1
ठीक है, लेकिन एक संख्यात्मक मान क्यों? परत बनाते समय हम अपनी कुंजी क्यों नहीं चुन सकते हैं?
जॉर्ज सिल्वा

1
मुझे लगता है कि मुख्य कारण यह है कि उन मान्यताओं में कोड लिखने का काम होता है जो जीआईएस पैकेज को बहुत अधिक आसान बनाता है।
blah238

4

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

..या आप एक साधारण ऑटोइन्क्रोमिंग पूर्णांक क्षेत्र को लागू कर सकते हैं।


4

जैसा कि कई लोगों ने सुझाव दिया है, यह सुविधा का सवाल है; लेकिन शायद अधिक गहराई से, यह सम्मेलन है।

एक प्रोग्रामर के रूप में, मेरी पहली वृत्ति परत आईडी के लिए एक संख्यात्मक कुंजी का उपयोग करना होगा, क्योंकि यह हमेशा ऐसा किया गया है। वास्तव में, यह मेरे लिए भी नहीं हो सकता है, कम से कम एक सचेत स्तर पर, कि मुझे इसे किसी अन्य तरीके से करना चाहिए। बेशक, अगर कोई तकनीकी कारण नहीं है कि पूर्णांक का उपयोग न करें, तो कहो कि 32-बिट्स (एक बहुत ही असंभावित प्रस्ताव!) में संग्रहीत होने की तुलना में अधिक परतें होने की संभावना है, या इसके लिए कोई व्यावसायिक कारण है या नहीं। तब विकल्पों पर विचार किया जाएगा।

संख्यात्मक कुंजियों के साथ एल्गोरिथम विचार भी हैं। सॉर्टिंग और सॉर्ट किए गए मानों की सूची की खोज अंततः दो नंबरों के बीच तुलना करने के लिए उबलती है, भले ही यह स्ट्रिंग्स या जटिल वस्तुओं की सूची हो; वे केवल एक हैशिंग फ़ंक्शन के साथ संख्याओं में बदल जाते हैं । कहा जा रहा है कि, आधुनिक कंप्यूटरों पर, 100 या 1000 वस्तुओं की सूची की खोज करना आमतौर पर एक जानवर-बल दृष्टिकोण के साथ उतना ही जल्दी होता है जितना कि यह एक उच्च अनुकूलित एल्गोरिदम के साथ होता है। जीआईएस में परतों के मामले में, मैं 1000 या अधिक से अधिक होने वाले नक्शे का सबसे जटिल भी नहीं देख सकता, और यहां तक ​​कि अगर ऐसा किया, तो अन्य संबद्ध संगणना एक अनुकूलित से किसी भी छोटे लाभ की तुलना में अधिक समय तक परिमाण के आदेश ले लेंगे। एक छोटी सूची की खोज।

पूर्णांक कुंजियाँ एक प्रोग्रामर के लिए "बस समझ में" आती हैं, और जैसा कि ब्रैड कहते हैं, गैर-संख्यात्मक कुंजियों का उपयोग करने में अधिक प्रयास है। शायद अधिक कोड नहीं, लेकिन अधिक मानसिक प्रयास, और हम आदत के आलसी जीव हैं। इसके अलावा, कुंजी जो विशिष्ट रूप से जीआईएस में एक परत की तरह कुछ की पहचान करती है, उपयोगकर्ता से "छिपी" मानी जाती है, यह सुनिश्चित करने के लिए कि वे इसके बारे में गड़बड़ नहीं करते हैं और कोड को तोड़ते हैं जो इसकी विशिष्टता पर निर्भर करता है (DB UNIQUE कीवर्ड नोटबंदी)। क्योंकि यदि आप एक उपयोगकर्ता को पर्याप्त रस्सी देते हैं, तो जल्द या बाद में कोई व्यक्ति खुद को इसके साथ लटकाएगा। हर तरह से उपयोगकर्ता-संपादन योग्य क्षेत्र पर विशिष्टता को लागू करता है, लेकिन अंतर्निहित प्रणाली को यह मान लेना चाहिए कि इसकी कुंजी अद्वितीय है और इससे अपरिचित है।


OpenStreetMap एक परियोजना है कि अधिक से अधिक 32-बिट पूर्णांकों की जरूरत है की एक उदाहरण है। वे bigintअपनी प्राथमिक कुंजी के लिए उपयोग करते हैं।
माइक टी।

तरीकों / नोड्स के लिए, हाँ। लेकिन मूल प्रश्न एक जीआईएस में परतों के बारे में था।
MerseyViking

OpenStreetMap जीआईएस परतों को संग्रहीत करता है।
जॉर्ज सिल्वा

OSM ऐसे तरीके और नोड्स संग्रहीत करता है जिनमें कुंजी / मान टैग होते हैं। यह प्रस्तुति प्रणाली (उदाहरण के लिए OpenLayers) और रेंडरिंग बैकेंड (उदाहरण के लिए Mapnik, Osmarender) पर निर्भर करता है ताकि उन टैग या कुछ और के आधार पर परतों की धारणा को निर्धारित किया जा सके। लेकिन माइक सही है, यह bigintअपने सभी टेबल की प्राथमिक कुंजी के लिए एस का उपयोग करता है ।
12:20 पर MerseyViking

यह उल्लेख करने के लिए +1 सम्मेलन के बारे में है। यह एक सम्मेलन है क्योंकि यह बेहतर प्रदर्शन के बराबर है।
कैप्टनड्रैगन

3

यह सवाल लोगों को (मेरे जैसे) एक भ्रमित करने वाला रहा है जो चीजों के जियोडेटबेस-साइड को विकसित करता है।

यह डेटाबेस संग्रहण की सीमा नहीं है, क्योंकि PostgreSQL विभिन्न डेटा प्रकारों के समग्र प्राथमिक कुंजी के साथ तालिकाओं को परिभाषित कर सकता है, हालांकि, इन तालिकाओं को QGIS जैसे कार्यक्रमों में लोड नहीं किया जा सकता है। संबंधित ऐतिहासिक नोट पर, PostgreSQL को एक आंतरिक कुंजी के रूप में एक OID कॉलम की आवश्यकता होती थी, जो कि 32-बिट पूर्णांक भी था। यह संस्करण 7.2 तक आवश्यक था ।

32-बिट पूर्णांक आईडी की आवश्यकता वास्तव में एक प्रोग्रामिंग सीमा है। एक निश्चित डेटा प्रकार (32-बिट पूर्णांक) के रूप में रिकॉर्ड के एक सेट के लिए एक इंडेक्स रखना बहुत सरल है, और इसके लिए उस रिकॉर्ड के लिए प्राथमिक कुंजी होना भी सुविधाजनक है। एक प्रोग्राम को एक प्राथमिक प्राथमिक कुंजी की अनुमति देना अधिक चुनौतीपूर्ण है, और इसके लिए कई और / या भिन्न प्रकार के डेटा के आधार पर एक अद्वितीय रिकॉर्ड प्राप्त करना है। हालाँकि, PostgreSQL के OID की तरह, इस सीमा को विकास के समय के साथ दूर किया जा सकता है। QGIS के लिए, [अब] 5 साल पुराने बग को किसी दिन हल किया जा सकता है ( विषय पर हाल की चर्चा )।


+1 खैर कहा। आगे के प्रमाणों के अनुसार कि यह एक प्रोग्रामिंग सीमा है, ध्यान दें कि ArcGIS 8.x के आने से पहले ESRI को ArcView में किसी भी आंतरिक पहचानकर्ता फ़ील्ड की आवश्यकता (या उपयोग) नहीं की गई थी। पुराना ArcView उन सभी डेटाबेस ऑपरेशनों में सक्षम था, जो आर्कगिस करता है (और वास्तव में उनमें से कई पर तेज था)।
whuber

2

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


मुझे लगता है कि जीआईएस संचालन के पास वास्तव में इसके साथ कुछ करना हो सकता है। प्रतिच्छेदन, (स्थानिक) यूनियनों, अंतर, आदि किसी को भी इस बात की पुष्टि या प्रस्तुत कर सकते हैं?
जॉर्ज सिल्वा

इस बात पर एक नज़र डालें कि ओरेकल जैसे एक एसडीई फीचर क्लास वास्तव में कैसे संग्रहीत किया जाता है। विशेषताओं के लिए एक तालिका है, ज्यामिति के लिए एक तालिका, स्थानिक सूचकांक के लिए एक तालिका, विशेषता अनुक्रमितों के लिए एक या एक से अधिक तालिकाओं, आदि। सभी अभी भी ArcView 3.x पर हैं।
blah238

@George - जैसा कि blah238 ने नोट किया है कि बहुत कम जीआईएस एप्लिकेशन हैं जो डेटा को स्टोर करने के लिए एक सिंगल फाइल का उपयोग करते हैं। जिसमें पैकेज के आधार पर निर्देशांक, उपाय, गुण, नियम, संबंध और बहुत कुछ शामिल हो सकते हैं। ऐसा करने में सक्षम होने के लिए यह अधिक है कि किस स्थानिक पंक्ति के साथ कौन सी विशेषता पंक्ति, किस नेटवर्क पंक्ति, के साथ आगे जाती है।
ब्रैड नेसोम

1
मुझे खेद है blah238, मुझे नहीं लगता कि इस मुद्दे में कोड का अमाउंट निर्धारक था। एनकाउंटर का इससे कोई लेना-देना नहीं है। डेटाबेस "गणित" करेगा और तय करेगा कि वर्णों का एक क्रम बराबर है या नहीं, इसलिए, PKEY को लागू करना। यह सॉफ्टवेयर लेयर पर नहीं है। @ ब्रैड नेसोम: यह भी समझ में आता है। लेकिन Oracle और PostGIS में आप अपनी सभी विशेषताओं को एक ही टेबल पर संग्रहीत कर सकते हैं। मैं मानता हूं कि आकार-प्रकारों को खतरनाक ऑब्जेक्ट की आवश्यकता थी ... और क्या यह मानक निर्धारित कर सकता है?
जॉर्ज सिल्वा

@George शेपफाइल्स की न तो जरूरत थी और न ही, सामान्य नियम के रूप में, एक ऑब्जेक्ट का उपयोग किया। उस OID फ़ील्ड को ArcGIS 8 के साथ पेश किया गया था। इसलिए मुझे संदेह है कि शेपफाइल्स का सवाल से कोई लेना-देना नहीं है।
whuber
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.