किसी भी SQL डेटाबेस में पता स्थान कैसे डिज़ाइन किया जाए?

Question

अवलोकन

मैं रिपोर्टिंग और कैलिफोर्निया के लिए मानचित्रण आवेदन कुछ आपातकालीन सेवाएं पर काम कर रहा हूँ (अजीब की तरह, वहाँ आग पर विचार, अभी ...)। हमें आंतरिक सरकारी इकाई के लिए जनसांख्यिकीय और आपातकालीन डेटा मानचित्रण करने की आवश्यकता है।

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

समस्या

मुझे यकीन है कि कैसे सबसे अच्छा डीबी टेबल डिजाइन करने के लिए नहीं कर रहा हूँ। हमें बताया नहीं गया है कि हमें किस प्रकार का डीबी उपयोग करने की ज़रूरत है .. इसलिए अगर हम मदद करते हैं तो हम सुझावों के लिए खुले हैं। हमारे पास एमएस एसक्यूएल 2005 और 2008 (और '08 में स्थानिक सामान) के साथ अनुभव है।

हमारे पास निम्न कानूनी डेटा हो सकता है।

• सड़क, शहर, राज्य
• शहर, राज्य
• पड़ोस, राज्य
• राज्य

कारण है कि राज्य एक कानूनी स्थान है, क्योंकि हमें बताया करते हैं कि इसमें हो सकता है अन्य राज्यों को बेचा गया, इसलिए हमें इसके लिए योजना बनाने की जरूरत है।

तो, मूल रूप से, मैं इस बारे में सोचा ...

• LocationId पूर्णांक पी पहचान
• स्ट्रीट NVARCHAR (100)
• पड़ोस NVARCHAR (100)
• शहर NVARCHAR (100)
• राज्य NVARCHAR (100)
• अक्षांश VARCHAR (15)
• रेखांश VARCHAR (15)
• शेपफ़ाइल

उन में से कोई भी व्यर्थ कर रहे हैं, btw। लेकिन थोड़ी देर के बाद, मैंने सोचा कि खेतों में इतने सारे 'कैलिफ़ोर्निया' टेक्स्ट या 'सैन डिएगो' टेक्स्ट होने का कचरा था। इसलिए मैंने नेबरहुड, सिटी और स्टेट फ़ील्ड को अपनी नई टेबल (उदाहरण के लिए लुकअप) के लिए एक विदेशी कुंजी बनाकर तालिका को और अधिक सामान्यीकृत करने के लिए बदल दिया .. और वे दो फ़ील्ड अब पूर्ण हैं।

तो .. यह सब ठीक काम करता है। सिवाय इसके कि जब मैं उन पर कुछ एसक्यूएल स्टेटमेंट्स कोशिश करता हूं और करता हूं। कुल एफके के कारण, यह इन सभी बाहरी प्रश्नों को बनाने के लिए एक दुःस्वप्न है :(

मुख्य तालिका, उप-लुकअप टेबल (उदाहरण के लिए पड़ोस, शहर और राज्य) आईडी के माध्यम से जुड़े हुए हैं और फिर सभी को रखने के बारे में क्या है यह एक दृश्य में है? याद रखें, पड़ोस और सीटीआईडीआईडी ​​पर्याप्त होगा .. ???

मैं सिर्फ इस पर लोगों के विचार देखना चाहता हूं और कारण उन्होंने अपने सुझाव दिए हैं।मैं वास्तव में चिंतित और उलझन में हूं लेकिन सीखने के लिए उत्सुक हूं।

कृपया मदद करें!

---

संपादित करें 1: मुझे एक RDBMS डेटाबेस से चिपकने की आवश्यकता है।

संपादित करें 2: मैं एक तालिका (डी-सामान्यीकृत) जाने के बारे में सोच रहा हूं ताकि बाधाओं के साथ unqiue या बहु सारणी को मुख्य तालिका (उदा। स्थान (मुख्य तालिका) , पड़ोस, शहर, राज्य ... सामान्यीकृत डीबी स्कीमा)।

संपादित करें 3: नमूना में जोड़ा गया शहर, दूसरी सूची।

संपादित करें 4: जोड़ा गया प्रश्न प्रश्न।

Answer 1

यह शुरू करने के लिए एक अच्छी जगह है। । एक पूरी # $ (# $ - डेटाबेस स्कीमा का लोड की जाँच करने के लिए:

http://www.databaseanswers.org/data_models/

Answer 2

यह एक समस्या मैं का सामना करना पड़ा है और आरडीबीएमएस सिस्टम श्रेणीबद्ध डेटा भंडारण में सबसे अच्छा नहीं कर रहे हैं आप हो सकता है ऑब्जेक्ट डेटाबेस का उपयोग करना चाहते हैं क्योंकि इन्हें नेस्टेड ऑब्जेक्ट्स से निपटना है और समस्या के लिए अनुकूलित किया गया है।

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

Answer 3

क्या यह एक ओएलटीपी सिस्टम और रिपोर्टिंग सिस्टम या केवल एक रिपोर्टिंग सिस्टम है? यदि यह केवल एक रिपोर्टिंग सिस्टम है, तो आप डेटा वेयरहाउस फैशन में डेटा को हिमस्खलन कर सकते हैं (हिमस्खलन आयामों के साथ या भौगोलिक क्षेत्राधिकारों के पदानुक्रमों के लिए नहीं) और आपको रिपोर्टिंग आसान हो जाएगी।

मैं परिणामों से शुरू करूंगा और वापस काम करूंगा, क्योंकि यह मुझे लगता है जैसे आप डेटा खिला रहे हैं और आप इसे रिपोर्टिंग और मैपिंग का समर्थन करने के लिए डेटाबेस में लाने की कोशिश कर रहे हैं। इस मामले में, डेटाबेस सामान्यीकृत सामान्यीकृत सिस्टम स्कीमा महत्वपूर्ण नहीं है क्योंकि डेटा में अनावश्यकता कुछ ऐसा नहीं है जो उपयोगकर्ताओं के लिए रखरखाव की समस्याएं पैदा करेगी।

यदि यह उचित लगता है, तो आप किमबाल किताबों को देखना चाहते हैं ।

Answer 4

@Oddthinking के रूप में एक टिप्पणी में बताया गया है, अपनी समस्याओं से शुरुआत की:

तो मैं मेज बदल पड़ोस करके अधिक सामान्यीकृत होने के लिए, शहर और राज्य अपने स्वयं नई तालिका के लिए एक विदेशी कुंजी (फ़ील्ड उदाहरण के लिए लुकअप) .. और वे दो फ़ील्ड अब पूर्ण हैं।

तो .. यह सब ठीक काम करता है। सिवाय इसके कि जब मैं उन पर कुछ एसक्यूएल स्टेटमेंट्स कोशिश करता हूं और करता हूं। कुल एफके की वजह से, इन सभी बाहरी प्रश्नों को बनाने के लिए यह एक दुःस्वप्न है।

यह मुझे "चिकित्सक, डॉक्टर, जब मुझे अपने आप को इस तरह हिट करता है तो दर्द होता है" की याद दिलाता है।

आपने विदेशी कुंजी फ़ील्ड को ठीक से क्यों बनाया?वे पहले अनिवार्य थे, इसलिए आपको बाहरी शामिल प्रश्नों के दुःस्वप्न से बचने के लिए, उन्हें अनिवार्य रूप से रखना चाहिए।

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

इसका मतलब है कि आपके पास कॉलर पड़ोस, नाम, सिटीआईडी ​​के साथ पड़ोसियों की एक तालिका हो सकती है; कॉलम सिटीआईडी, नाम, राज्य के साथ शहरों की एक मेज; और कॉलम राज्य और नाम के साथ राज्यों की एक मेज। आप फिट बैठते हुए अन्य कॉलम जोड़ सकते हैं। और आपकी प्राथमिक तालिका में एक पड़ोस की कॉलम होगी जो पड़ोस की मेज के लिए एक विदेशी कुंजी है।

Answer 5

उदाहरण लें:

• सड़क, शहर, राज्य
• शहर, राज्य
• पड़ोस, राज्य
• राज्य

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

तो अपना पता तालिका एक और तालिका में एक 1-अनेक संबंध की जरूरत है, इस प्रकार address_entities कहा जाता है जो:

• पूर्णांक आईडी
• varchar () नाम
• varchar() टाइप
• पूर्णांक parentID
• भूगोल स्थिति।
• पूर्णांक parentID

इसका मतलब यह है कि आप स्पष्ट रूप से ऊपर दिए गए पते इकाई मेज पर पता जोड़ने के लिए एक मेज की आवश्यकता होगी। अब, प्रत्येक भू-स्थानिक इकाई स्वाभाविक रूप से पदानुक्रमित है, और जब तक यह SQL को कठिन बनाता है, और व्यक्तिगत रूप से मैं आत्म संदर्भ तालिका से बचने की कोशिश करता हूं, ऐसे समय होते हैं जब यह एक अच्छा समाधान होता है और यह उनमें से एक है।

लाभ भारी हैं, भले ही यह कोड को कठिन बनाता है, यह लंबे समय तक इसके लायक है।

इसके अलावा, तब भी जब यह एक तत्काल आवश्यकता नहीं है, विश्व स्तर पर लगता है, नहीं दुनिया में सभी पते में एक सड़क का है, या राज्य, उदाहरण के लिए, फ्रांस में एक मान्य पता

- la Maison des Fou 
- 24500 Eymet 

तो हो सकता है , स्कीमा डिजाइन करते समय इसे ध्यान में रखें।