मैं 256+ चर के साथ तालिकाओं को कैसे संभाल सकता हूं?

Question

मैं जनगणना के डेटा के साथ काम कर रहा हूं और कई CSV फ़ाइलों को डाउनलोड किया है, जिनमें से प्रत्येक 600ish कॉलम / चर के साथ है। मैं उन सभी को एक क्वेरी-सक्षम डेटाबेस में संग्रहीत करना चाहता हूं, लेकिन मैंने अब तक (एमएस एक्सेस, आर्क जियोडैटेबेस टेबल) जो भी कोशिश की है, वह तालिका को 256 स्तंभों में विभाजित करता है। क्या बड़े टेबल को संभालने के लिए कोई समाधान है जो किसी डीबीए के लिए सुलभ नहीं है?

Comments

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

— रॉय

Answer 1

PostgreSQL में "स्तंभ प्रकारों के आधार पर" 250 और 1600 के बीच की एक स्तंभ सीमा होती है, और PostGIS एक्सटेंशन के साथ स्थानिक डेटा और प्रश्नों का समर्थन करता है। इसलिए मैं दो काम करना चाहूंगा:

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

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

एक और पूरी तरह से अलग विकल्प एक "NOSQL" डेटाबेस का उपयोग करना होगा जैसे कि MongoDB, CouchDB, और इसी तरह। "पंक्ति" आकार में कोई हार्ड-वायर्ड सीमाएं नहीं हैं, और यदि डेटा रिकॉर्ड के लिए मौजूद नहीं है, तो इसे किसी भी स्थान को लेने की आवश्यकता नहीं है।

इन प्रकार के बिगटेबल डेटाबेस के लिए स्थानिक समर्थन उतना अच्छा नहीं है, लेकिन MongoDB 2D स्थानिक प्रश्नों और डेटा का समर्थन करता है, और CouchDB में समान कार्यक्षमता है।

Comments

+1 ज्वाइन सॉल्यूशन (पैराग्राफ 3) वास्तव में बेहद कुशल हो सकता है, क्योंकि जनगणना के आंकड़ों में संबंधित क्षेत्रों के समूह होते हैं और किसी विशेष विश्लेषण के लिए अक्सर इन समूहों की एक छोटी संख्या की आवश्यकता होती है। इस फैशन में हजारों फ़ील्ड (मैं अतिशयोक्ति नहीं करता हूं: यह आम है) को दर्जनों तालिकाओं के पार तार्किक रूप से तोड़ा जा सकता है और केवल उन तालिकाओं की एक छोटी संख्या को किसी विशेष मानचित्र या विश्लेषण के लिए एक्सेस करने की आवश्यकता होती है।

— whuber

@MerseyViking, अगर वह तालिकाओं में हेरफेर करने वाले किसी भी कार्यक्रम में डेटा आयात नहीं कर सकता, तो वह (@scoball) स्प्लिट टेबल या अन्य उल्लिखित संचालन कैसे कर सकता है? डेटा CSV में है।

— पाब्लो

@ पाब्लो, मुझे लगता है कि आप MerseyViking के साथ अन्याय कर रहे हैं: यदि आपको तालिकाओं को आयात करने के लिए स्क्रिप्ट लिखने की अनुमति है - जिसे आप अनिवार्य रूप से अपने समाधान को लागू करने के लिए मजबूर कर रहे हैं - तो वह है, और कोई कठिनाई नहीं है एक ऐसा लेखन जो पूरी तरह से सामान्य और लचीला हो। (मैं इसे अनुभव से जानता हूं क्योंकि मैंने इसे बहुत बड़ी जनगणना डेटाबेस के लिए किया है।) इसके अलावा, वह कई विकल्प सुझाता है जो 256 क्षेत्र सीमा के आसपास काम करते हैं।

— whuber

"जहां एक कॉलम मुक्त पाठ के बजाय एक श्रेणी का प्रतिनिधित्व करता है" आपको उन कॉलमों को मैन्युअल रूप से मैप करना होगा।

— पाब्लो

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

— whuber

Answer 2

मैंने हाल ही में सांख्यिकी कनाडा की जनगणना प्रोफ़ाइल CSV फ़ाइलों के साथ 2172 कॉलम वाली एक ही समस्या से निपटा है। यदि आप ArcGIS तक पहुँच रखते हैं, तो आप अपने सीएसवी को एक ESRI फ़ाइल जियोडैटेबेस (FGDB) में आयात कर सकते हैं। ईएसआरआई के अनुसार, एफजीडीबी प्रारूप फीचर क्लास या टेबल में 65,534 क्षेत्रों को संभाल सकता है ।

मेरे मामले में, मैं अपनी 2172 कॉलम चौड़ी CSV फ़ाइल को बिना किसी समस्या के FGDB तालिका में आयात करने में सक्षम था।

एक बार जब आप FGDB में पूरी तालिका प्राप्त कर लेते हैं, तो आप इसे अपनी पसंद के अनुसार किसी भी तरह से स्लाइस कर सकते हैं (जैसे। तार्किक रूप से या db सीमाओं के आधार पर), यह सुनिश्चित करते हुए कि आप एक अद्वितीय आईडी कॉलम रखते हैं, यह सुनिश्चित करने के लिए कि आप इसे वापस एक साथ जोड़ सकते हैं। जरूरत है।

Comments

दिलचस्प! मैंने जीओवीटी से जियोडैटबेस फाइल करने के लिए इम्पोर्ट करने की कोशिश की। जब मैं इसे सेट कर रहा था तो मैंने चर की सूची को देखा जो इसे आयात करने जा रहा था और इसने 256 चर के बाद उन्हें सूचीबद्ध करना बंद कर दिया था, इसलिए यह आगे नहीं बढ़ा। मैं एक और नज़र डालूंगा।

— scoball

इस लिंक को देखें: wealth.nhgis.org/How_to_Import_256_Columns_GIS.pdf

— ब्रेंट एडवर्ड्स

फ़ाइल जियोडैट डेटाबेस की उच्च सीमा है, इसलिए यह संभव है कि आयात में कुछ हुआ है।

— निक्सन

Answer 3

संक्षिप्त:
बहुत सी विशेषताओं वाले डेटा के लिए या प्रत्येक ऑब्जेक्ट के लिए वैरिएबल एट्रीब्यूट प्रकार के साथ मेरा विकल्प KEY / VALUE डेटा मॉडल का उपयोग करना है, इसे कार्यान्वित किया जा सकता है, और sql में (मैं postgresql + पोस्टगिस की सिफारिश करूंगा) बहुत अच्छा काम करता है।

विवरण:
1) आपके पास सुविधाओं के लिए एक तालिका है, आइए बताते हैं, अंक। यह तालिका प्रत्येक बिंदु के लिए एक आईडी और GEOMETRY रखती है।

2) आपके पास 'विशेषताओं' के लिए एक और तालिका है जो कुंजी / मान युग्म है। इस तालिका में कॉलम ID, POINT_ID (FK), कुंजी (varchar), VALUE (varchar) है।

अब प्रत्येक बिंदु में लगभग अनंत गुण हो सकते हैं जैसे कि:

ID   POINT_ID   KEY   VALUE
1        1      type     burger shop
2        1      name     SuperBurger
3        1      address  123, a ST.

OpenStreetMaps उस तरह से काम करता है और बहुत अच्छी तरह से काम करता है, यहां और यहां देखें ।

डेटा आयात करने के लिए मैं एक पायथन स्क्रिप्ट का प्रयोग करूंगा।

Comments

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

— whuber

@whuber, यह मल्टीवेरिएट विश्लेषण के लिए बेकार नहीं है, लेकिन वास्तव में आपको एक बहुत ही संरचित सॉफ्टवेयर या अच्छे प्रोग्रामिंग कौशल की आवश्यकता होती है क्योंकि डेटा को तैयार करने की आवश्यकता होती है, विशेष रूप से, एक टेबल पर स्थानांतरित कर दिया जाता है। यहाँ मुझे पोस्टगिस + डीजेंगो (पायथन वेब फ्रेमवर्क) के संयोजन का उपयोग मिट्टी के डेटा (ph, al, क्ले, आदि) पर काम करने के लिए होता है जब मुझे आवश्यकता होती है कि मैं प्रसंस्करण से पहले डेटा का अंश तालिकाओं में डाल दूं। इस मॉडल को इसलिए चुना गया क्योंकि एक ही संरचना अन्य मनमाने ढंग से समय पर डेटा संसाधित करेगी।

— पाब्लो

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

— whuber

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

— पाब्लो

आपका समाधान लगता है, अपने स्वयं के प्रवेश द्वारा, प्रोग्राम के रूप में जटिल रूप में मेरा - "अच्छे प्रोग्रामिंग कौशल" की आवश्यकता है। मैंने केवल डेटा को एक ऐसे रूप में रखने की वकालत की है जो RDBMS जैसे PostgreSQL के लिए सबसे अधिक कुशल है। इसके अलावा, यह एक मूक बिंदु प्रतीत होता है क्योंकि ब्रेंट का उत्तर दिखाता है कि 256 कॉलम सीमा फर्जी है।

— MsyViking