दूसरा विचार (चयन के लिए बूलियन विशेषता बनाने के लिए) के कई फायदे हैं :
(i) यह स्पष्ट रूप से दस्तावेज करता है कि क्या लेबल करने की आवश्यकता है,
(ii) यह अंतर्निहित डेटासेट की तरह स्थायी और पोर्टेबल है,
(iii) यह निर्धारित करने के लिए एक सरल और प्रत्यक्ष तंत्र प्रदान करता है कि कौन से लेबल दिखाई देंगे (जो कि दूसरे जीआईएस या प्लॉटिंग पैकेज के लिए भी पोर्टेबल है),
(iv) लेबल के इन विकल्पों और किसी भी अन्य चर के बीच संबंधों के बारे में प्रश्न होने पर, विश्लेषण करना और भी आसान है, और
(v) ग्राहक की पसंद को बेहतर तरीके से एन्कोडिंग द्वारा, यह कोई डुप्लिकेट जानकारी नहीं बनाता है।
यहां कुछ सामान्य डेटाबेस निर्माण और प्रबंधन सिद्धांत काम करते हैं , जैसा कि बुद्धिमानी से प्रश्न में सुझाया गया है। उनमें से एक यह है कि यदि संभव हो तो जानकारी के किसी भी सुसंगत टुकड़े को डेटाबेस में विशिष्ट रूप से दर्शाया जाना चाहिए । (निश्चित रूप से विभिन्न तालिकाओं में संबंधित अभिलेखों की पहचान के रूप में, जॉन्स को कार्यान्वित करने के लिए कुंजी के रूप में उपयोग की जाने वाली जानकारी को इसके कार्य के कई स्थानों में प्रकट होना चाहिए।) इस सिद्धांत के उत्कृष्ट कारण हैं, क्योंकि किसी भी व्यक्ति ने गैर-सामान्य बनाए रखने का प्रयास किया है। रिलेशनल डेटाबेस प्रमाणित कर सकते हैं: अगर आप लगातार अपडेट करने या हटाने या को यह जानकारी जोड़ने के लिए याद नहीं है कि हर वह तालिका जिसमें यह दिखाई देता है, आपका डेटाबेस जल्द ही आंतरिक रूप से असंगत हो जाता है: यह भ्रष्ट है, अक्सर ऐसा नहीं होता है।
एक और सिद्धांत यह है कि एक अच्छे संबंधपरक डेटाबेस डिजाइन में, प्रत्येक तालिका को एक एकल वैचारिक "अस्तित्व" का प्रतिनिधित्व करना चाहिए : कुछ ऐसा जो डेटा मॉडलिंग कर रहा है या उन चीजों के बीच एक संबंध है। जब कोई ग्राहक विशेषताओं के एक मनमाने ढंग से चयन को निर्दिष्ट करता है, तो वे एक तालिका में पंक्तियों के सबसेट को प्रभावी ढंग से निर्दिष्ट कर रहे हैं। गणितीय रूप से, पृथक्करण के स्वयंसिद्ध द्वारा यह बूलियन फ़ील्ड के साथ उन्हें फ़्लैग करने के समान है। इस प्रकार, डेटाबेस में चीजों के किसी भी अर्थपूर्ण "मनमाने" उपसमुच्चय को बूलियन फ़ील्ड द्वारा दर्शाया जा सकता है और, इसके विपरीत, इस तरह के क्षेत्र में मनमाना सबसेट (या चयन) को संग्रहीत करने का एक अच्छा तरीका है।
फिर भी एक और सिद्धांत यह है कि आपको जानकारी संग्रहीत करने के लिए जीआईएस की अंतर्निहित डेटा प्रबंधन क्षमताओं का उपयोग करना पसंद करना चाहिए । विकल्प कुछ तदर्थ हैजीआईएस की क्षमता के आधार पर विधि अपनी "प्रोजेक्ट फाइलों" के भीतर या किसी अन्य स्वतंत्र तरीके से जानकारी संग्रहीत करने के लिए। इसका एक विशिष्ट उदाहरण मैन्युअल रूप से वांछित लेबल चुनने और रखने का अभ्यास है। अक्सर ऐसा करना त्वरित और आसान होता है। जब भी किसी बदलाव की जरूरत होती है या काम को फिर से शुरू करने की आवश्यकता होती है तो समस्याएं उत्पन्न होती हैं; इन स्थितियों में से एक या व्यावहारिक रूप से अपरिहार्य है। लेबल का मैनुअल प्लेसमेंट स्टोरिंग सूचना (अर्थात्, सुविधाओं के सबसेट को लेबल किया जाना चाहिए) के लिए टेंडमाउंट आरडीबीएमएस के बाहर बेहद अण्डाकार रूप में है। अर्थात्, चयन केवल निर्दिष्ट करता है कि कौन से लेबल दिखाई देते हैं और कौन से नहीं। इस बारे में सोचें कि आप इन समस्याओं का समाधान कैसे करेंगे:
क्लाइंट चाहता है कि एक ही लेबल संबंधित लेकिन अलग-अलग नक्शे में दिखाई दे, एक अलग प्रोजेक्ट का हिस्सा।
एक प्रश्न यह उठता है कि क्या लेबल किसी अन्य विशेषता के साथ जुड़े हैं।
समय के साथ लेबलों में कई बदलाव करने के बाद, आपको मूल संस्करण पर वापस जाने के लिए कहा जाता है।
इन मामलों में, समस्या को हल करने के लिए शामिल काम भारी हो सकता है: आपको फिर से सभी लेबलिंग को फिर से करना होगा, या डेटाबेस तालिकाओं के खिलाफ मैनुअल क्रॉस-चेक करना होगा, या एक पुरानी संग्रहीत परियोजना फ़ाइल को ढूंढना और पुनर्स्थापित करना होगा। यदि डेटाबेस में लेबल को बूलियन फ़ील्ड द्वारा दर्शाया गया था, तो इसके बजाय कार्य लगभग तुच्छ होगा।
