कुछ सूचियों के साथ वीएस शब्दकोश के साथ कई शब्दकोशों की सूची?

Question

मैं बहुत तरह डेटासेट के साथ कुछ अभ्यास कर रहा हूँ:

कई शब्दकोशों कुछ सूचियों के साथ

users = [ 
    {"id": 0, "name": "Ashley"}, 
    {"id": 1, "name": "Ben"}, 
    {"id": 2, "name": "Conrad"}, 
    {"id": 3, "name": "Doug"}, 
    {"id": 4, "name": "Evin"}, 
    {"id": 5, "name": "Florian"}, 
    {"id": 6, "name": "Gerald"} 
] 

शब्दकोश

users2 = { 
    "id": [0, 1, 2, 3, 4, 5, 6], 
    "name": ["Ashley", "Ben", "Conrad", "Doug","Evin", "Florian", "Gerald"] 
} 

पांडा dataframes

के साथ सूची

सवाल:

1. मैं उन या की तरह users2 तरह डेटासेट संरचना करना चाहिए?
2. क्या प्रदर्शन अंतर हैं?
3. क्या एक दूसरे की तुलना में अधिक पठनीय है?
4. क्या कोई मानक मुझे पालन करना चाहिए?
5. मैं आमतौर पर इन्हें पांडा डेटाफ्रेम में परिवर्तित करता हूं। जब मैं ऐसा करता हूं, तो दोनों संस्करण समान होते हैं ... सही?
6. उत्पादन प्रत्येक तत्व के लिए सच है, इसलिए इससे कोई फर्क नहीं पड़ता कि मैं पांडा डीएफ के अधिकार के साथ काम करता हूं?

Answer 1

यह column oriented databases उन्मुख पंक्ति बनाम से संबंधित फायदे जानने के लिए करना चाहते हैं। आपका पहला उदाहरण एक पंक्ति उन्मुख डेटा संरचना है, और दूसरा कॉलम उन्मुख है। पायथन के विशेष मामले में, पहले को slots का उपयोग करके विशेष रूप से अधिक कुशल बनाया जा सकता है, जैसे कॉलम के शब्दकोश को प्रत्येक पंक्ति के लिए डुप्लीकेट करने की आवश्यकता नहीं है।

कौन सा फॉर्म बेहतर काम करता है, इस पर निर्भर करता है कि आप डेटा के साथ क्या करते हैं; उदाहरण के लिए, पंक्ति उन्मुख प्राकृतिक है यदि आप केवल किसी भी पंक्ति तक पहुंचते हैं। इस बीच कॉलम उन्मुख कैशों का बेहतर उपयोग करता है और इस तरह जब आप किसी विशेष क्षेत्र से खोज रहे होते हैं (पायथन में, इसे संदर्भों के भारी उपयोग से कम किया जा सकता है; array जैसे प्रकार इसे अनुकूलित कर सकते हैं)। पारंपरिक पंक्ति उन्मुख डेटाबेस अक्सर कॉलम उन्मुख सॉर्ट किए गए इंडेक्स का उपयोग लुकअप को गति देने के लिए करते हैं, और इन तकनीकों को जानना आप किसी कुंजी-मूल्य स्टोर का उपयोग करके किसी भी संयोजन को कार्यान्वित कर सकते हैं।

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

आपके उदाहरण में एक तीसरा विकल्प स्पष्ट नहीं है: इस मामले में, आपके पास केवल दो कॉलम हैं, जिनमें से एक 0 से एक संगत रेंज में एक पूर्णांक आईडी है। इसे प्रविष्टियों के क्रम में ही संग्रहीत किया जा सकता है, जिसका अर्थ है कि पूरी संरचना उस सूची में मिलेगी जिसे आपने users2['name'] कहा है; लेकिन विशेष रूप से, प्रविष्टियां उनकी स्थिति के बिना अपूर्ण हैं। सूची enumerate() का उपयोग कर पंक्तियों में अनुवाद करती है। डेटाबेस के लिए यह विशेष मामला भी आम है (उदाहरण के लिए, स्क्लाइट rowid)।

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

Answer 2

users सामान्य रूप से वास्तव में user तत्वों का संग्रह है। तो एक स्टैंडअलोन इकाई के रूप में user तत्व को परिभाषित करना बेहतर है। तो आपका पहला विकल्प सही है।

Answer 3

में लुकअप के लिए

समय जटिलता -

• सूची - हे (एन)
• Dicts - हे (1)

लेकिन वह ज्यादा चोट नहीं होगा यदि आपके डेटा 'isn टी कि बड़े और आधुनिक दिन प्रोसेसर काफी कुशल हैं।
आपको उस व्यक्ति के साथ जाना चाहिए जिसमें लुकअप वाक्य रचनात्मक रूप से क्लीनर और पठनीय (पठनीयता संबंधी मामलों) है।
पहला विकल्प काफी उपयुक्त है क्योंकि परिवर्तक उपयोगकर्ताओं का संग्रह है (जिसे एक आईडी असाइन किया गया है) जबकि दूसरा उपयोगकर्ता नाम और आईडी का संग्रह होगा।

Answer 4

उपयोगकर्ता

1. जब आप बस सभी उपयोगकर्ता जानकारी का एक नया dict बनाने के लिए और यह

2. आसानी @StevenRumbalski रूप sortable सुझाव

3. संलग्न कुछ नए उपयोगकर्ता संलग्न करने के लिए की जरूरत है खोज आसान होगा

4. इस रूप में रिकॉर्ड

Users2

1. व्यक्तिगत रूप से मैं देख रहा हूँ (कुछ रिकॉर्ड बहुत अधिक संख्या मुझे लगता है कि हम भी कुछ उपयोगकर्ताओं की तुलना में बेहतर की आवश्यकता होगी के लिए) बढ़ता है अधिक कॉम्पैक्ट और आसानी से प्रबंधनीय है यह पहली बार है और यदि मेरे पास उच्च संख्या में रिकॉर्ड हैं तो मैं इससे संपर्क नहीं करूंगा।

पुनश्च: लेकिन मैं की users2users से अधिक फिर एक अच्छा सवाल

Answer 5

शब्दकोशों की सूची का पहला विकल्प काफी कुछ कारणों से बेहतर होगा। सूची EXTEND, APPENT, PUSH जैसी विधियां प्रदान करती है जो शब्दकोशों के साथ आसानी से उपलब्ध नहीं हैं।

Answer 6

पांडा पहलू के बारे में कुछ जवाब:

1. दोनों dataframes वास्तव में ही कर रहे हैं और स्तंभ उन्मुख, जो अच्छा है, क्योंकि पांडा सबसे अच्छा काम करता है जब प्रत्येक स्तंभ में डेटा सजातीय है (यानी संख्या के रूप में संग्रहित किया जा सकता इनट्स और फ्लोट्स)। पहली जगह में पांडा का उपयोग करने का एक मुख्य कारण यह है कि आप वेक्टरकृत संख्यात्मक संचालन कर सकते हैं जो कि शुद्ध पायथन की तुलना में तीव्रता के क्रम हैं - लेकिन जब यह विषम प्रकार का होता है तो यह कॉलमर संगठन पर निर्भर करता है।
2. यदि आप चाहें तो ट्रांसफर करने के लिए pd_users.T कर सकते हैं, और फिर देखेंगे (info() या dtypes के माध्यम से) कि सबकुछ तब सामान्य उद्देश्य ऑब्जेक्ट के रूप में संग्रहीत किया जाता है क्योंकि कॉलम में स्ट्रिंग और संख्या दोनों होते हैं।
3. एक बार परिवर्तित हो जाने पर, आप pd_users.set_index('id') कर सकते हैं ताकि आपका डेटाफ्रेम अनिवार्य रूप से id कुंजी के साथ एक शब्दकोश हो। या इसके विपरीत name के साथ।
4. इंडेक्स बदलने के लिए यह बहुत आम (और आमतौर पर बहुत तेज़) है, फिर पांडा के साथ काम करते समय उन्हें वापस, स्थानांतरित करें, सबसेट इत्यादि बदलें, इसलिए शुरुआत में संरचना के बारे में बहुत कुछ सोचना आवश्यक नहीं है। बस इसे फ्लाई पर करने की जरूरत के रूप में इसे बदलें।
5. यह टेंगेंट पर हो रहा है, लेकिन आपके ऊपर जो कुछ है, उसका एक आसान पांडा एनालॉग DataFrame के बजाय Series हो सकता है। एक श्रृंखला अनिवार्य रूप से डेटाफ्रेम का एक कॉलम है हालांकि यह वास्तव में एक इंडेक्स ("कुंजी") के साथ केवल एक-आयामी डेटा सरणी है।

त्वरित डेमो (dataframe नाम, आम सम्मेलन के रूप में df उपयोग करते हुए):

>>> df.set_index('name') 

     id 
name  
Ashley 0 
Ben  1 
Conrad 2 
Doug  3 
Evin  4 
Florian 5 
Gerald 6 

>>> df.set_index('name').T 

name Ashley Ben Conrad Doug Evin Florian Gerald 
id   0 1  2  3  4  5  6 

>>> df.set_index('name').loc['Doug'] 

id 3 
Name: Doug, dtype: int64