डेटाबेस का उपयोग करके डेटा संरचनाओं और एल्गोरिदम का उपयोग करने वाले एल्गोरिदम के बीच अंतर क्या हैं?


10

सामान्य प्रश्न

डेटाबेस का उपयोग करके डेटा संरचनाओं और एल्गोरिदम का उपयोग करने वाले एल्गोरिदम के बीच अंतर क्या हैं?

कुछ प्रसंग

यह एक ऐसा सवाल है जो पिछले कुछ समय से मुझे परेशान कर रहा है, और मैं इसके लिए ठोस जवाब नहीं दे पा रहा हूं।

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

मैं डेटा को संग्रहीत करने के लिए एक दैनिक आधार पर डेटाबेस का भी उपयोग करता हूं जिसे एंड-यूज़र द्वारा संसाधित और प्रस्तुत किया गया है या प्रोग्राम द्वारा संसाधित किया गया है। मैं एक DAL के माध्यम से डेटा को पुनः प्राप्त और सबमिट करता हूं, जिसकी खुद की डेटा संरचनाएं हैं जो डेटाबेस में तालिकाओं के आधार पर उत्पन्न होती हैं।

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

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

तो यहां प्रश्न हैं ...

प्रशन

  1. डेटा संरचनाओं और डेटाबेस के बीच अंतर क्या हैं?
  2. हम एल्गोरिदम का उपयोग कब करते हैं जो केवल आपके तर्क के भीतर परिभाषित डेटा संरचनाओं का उपयोग करते हैं और डेटाबेस के नहीं?
  3. @ हाईवे पोस्ट: जब डेटाबेस में विधियाँ अपने स्वयं के तर्क की विधियों की तुलना में उपयोग करने के लिए कम कुशल हो जाती हैं?
    • @mirculixx पोस्ट: क्या एक विधि कुशल बनाता है?
  4. @ हाईवे पोस्ट: डेटाबेस में इसे करने से डेटा संरचनाओं के साथ डेटा को तेजी से कैसे संसाधित किया जाता है?

स्पष्टीकरण

  1. @ अच्छी पोस्ट: जिन डेटाबेसों के साथ मैं आमतौर पर काम करता हूं वे रिलेशनल हैं, और ये सवाल उनके साथ काम करने से आ रहे हैं। हालांकि, मुझे लगता है कि ये प्रश्न किसी भी दृढ़ता ढांचे पर लागू होते हैं (जब मैं रूपरेखा कहता हूं, तो मेरा मतलब है कि यह सबसे सामान्य अर्थ में है)।

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


Datomic.com डेटाबेस पारंपरिक संबंधपरक की तुलना में उपयोगकर्ता के करीब है। क्या आप केवल पारंपरिक डेटाबेस देख रहे हैं?
जॉब

@ जोब नहीं, संबंधपरक डेटाबेस केवल एक चीज नहीं है जो मैं यहां पर विचार कर रहा हूं। यह डेटाबेस / दृढ़ता इकाई में डेटा संरचनाओं में तर्क बनाम डेटा संरचनाओं के बीच अंतर को समझने के बारे में अधिक है।
हुलकेमिस्टर

एक सामान्य नियम के रूप में, मैं कहूंगा - यदि आप कर सकते हैं तो एक डेटाबेस का उपयोग करें, लेकिन अगर यह बहुत धीमा हो जाता है, तो डेटा संरचनाओं का उपयोग करने का सहारा लें। डेटा दोहराव (जैसे कैशिंग) खराब है क्योंकि आपको दोनों को सिंक में रखना है, इसलिए जब तक आप नहीं कर सकते हैं, तब तक इससे बचें।
नौकरी

डेटाबेस को डेटा केवल इसे सॉर्ट करने के लिए भेजें? अपने दिमाग को बदलने के लिए ब्लॉक के आसपास ड्राइविंग की तरह?

जवाबों:


18

डेटा संरचनाएं, अधिकांश भाग के लिए हैं:

  1. स्मृति निवासी,
  2. क्षणिक,
  3. आकार में सीमित,
  4. ताले या अपरिवर्तनीयता जैसे संगामिति तंत्रों को जोड़े बिना पुनः प्रवेश नहीं,
  5. ACID अनुपालन नहीं ,
  6. उपवास, अगर ध्यान से चुना जाए।

अधिकांश भाग के लिए डेटाबेस हैं:

  1. डिस्क बाध्य,
  2. लगातार,
  3. विशाल,
  4. सुरक्षित रूप से समवर्ती,
  5. एसीआईडी ​​अनुपालन, व्यवहारिक क्षमताओं के साथ ,
  6. डेटा संरचनाओं की तुलना में धीमी

डेटा संरचनाओं को एक स्थान से दूसरे स्थान पर पारित किया जाना है, और आंतरिक रूप से एक कार्यक्रम के भीतर उपयोग किया जाता है। जब आपने पिछली बार डेटाबेस का उपयोग करके वेब पेज से वेब सर्वर पर डेटा भेजा था, या डेटाबेस पर गणना की थी जो पूरी तरह से मेमोरी में निवासी था?

डेटाबेस सिस्टम डेटा संरचनाओं का उपयोग उनके आंतरिक कार्यान्वयन के हिस्से के रूप में करते हैं। यह आकार और दायरे का सवाल है; यदि आप अपने कार्यक्रम के भीतर डेटा संरचनाओं का उपयोग करें, लेकिन एक डाटाबेस सिस्टम है अपने आप में एक कार्यक्रम।


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

1
खैर, यह दाल की रोटी और मक्खन है, है ना? ऑब्जेक्ट और डेटाबेस रिकॉर्ड के बीच संक्रमण को कम करने के लिए DAL का अस्तित्व है। DAL लगभग 80 से 90 प्रतिशत के लिए अच्छा है कि आप एक डेटाबेस के साथ क्या करना चाहते हैं लेकिन, शेष 10 से 20 प्रतिशत के लिए, आप कच्चे SQL या संग्रहीत कार्यविधियों पर वापस जाना चाहते हैं, क्योंकि यह अधिक कुशल है।
रॉबर्ट हार्वे

आपके सॉर्टिंग / फ़िल्टरिंग के उदाहरण में, आप सही हैं कि आप संभवतः डेटाबेस सर्वर पर उस तरह की प्रोसेसिंग करना चाहते हैं। लेकिन आप सबसे अधिक संभावना अभी भी डेटा संरचना के कुछ रूप के रूप में उस प्रसंस्करण का परिणाम प्राप्त करेंगे।
रॉबर्ट हार्वे

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

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

6

डेटा संरचनाओं और डेटाबेस के बीच अंतर क्या हैं?

एक अमूर्त स्तर पर, वहाँ कोई नहीं है - एक डेटाबेस है एक डेटा संरचना।

एक विशिष्ट स्तर पर, डेटाबेस में आमतौर पर डेटा को बनाए रखने का उद्देश्य होता है, आमतौर पर एक प्रारूप में जो कि सम्मिलन, अद्यतन, पुनर्प्राप्ति, किसी अन्य उद्देश्य (या संयोजन) के लिए अनुकूलित होता है।

उदाहरण के लिए, यदि आप डेटा की एक सरणी कहने के लिए RDBMS में एक तालिका की तुलना करते हैं, तो अंतर एल्गोरिथ्म के रन-टाइम में हो सकता है, आपके द्वारा लिखे जाने वाले कोड की मात्रा, एल्गोरिथम को चलाने के लिए आपके द्वारा आवश्यक मेमोरी की मात्रा या आपके प्रोग्राम / एल्गोरिदम के बाहर से डेटा को काम करने / उपयोग करने का लचीलापन।

हम एल्गोरिदम का उपयोग कब करते हैं जो केवल आपके तर्क के भीतर परिभाषित डेटा संरचनाओं का उपयोग करते हैं और डेटाबेस के नहीं?

प्रवृत्ति में मैं बहस करूँगा

क) डेटाबेस का उपयोग करने के लिए यदि आपको उस तरीके से डेटा को बनाए रखने की आवश्यकता है जो रन-टाइम या विशिष्ट एल्गोरिथम के उद्देश्य से परे सुलभ है।

ख) यदि रन-टाइम गति मायने रखती है, या दृढ़ता की आवश्यकता नहीं है, तो अपने स्वयं के (इन-मेमोरी) डेटा संरचना का उपयोग करने के लिए

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

ध्यान दें, हालांकि, इन-मेमोरी डेटाबेस की अवधारणा है जो प्रदर्शन कारणों से जरूरी डेटा को बनाए नहीं रखते हैं। जैसे रेडिस या हाना

जब डेटाबेस में विधियाँ अपने स्वयं के तर्क के तरीकों की तुलना में कम कुशल हो जाती हैं?

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

डेटाबेस में इसे करने से डेटा संरचनाओं के साथ डेटा को तेजी से कैसे संसाधित किया जाता है?

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


1

डिस्क का उपयोग मुख्य रूप से इस ऑपरेशन में सबसे महंगा है, नेटवर्क एक्सेस (http://serverfault.com/questions/238417/are-networks-now-faster-than-disks) की तुलना में अधिक बार। जब तक आपका डेटाबेस कम से कम 1 Gbps नेटवर्क और आपके वेब \ अनुप्रयोग सर्वर के समान नेटवर्क पर स्थित नहीं होता है, तब तक नेटवर्क का प्रदर्शन बड़े डेटासेट के लिए डिस्क प्रदर्शन जितना मायने नहीं रखेगा। या यदि आपका डेटा बहुत तेजी से ठोस राज्य डिस्क पर निवास करता है जो तेजी से तब ठेठ नेटवर्क का उपयोग होगा। इसके अलावा, डेटाबेस आमतौर पर टीसीपी / आईपी का उपयोग करने के बजाय नामित पाइप जैसे एक आईपीसी तंत्र प्रदान करते हैं यदि डेटाबेस आपके एप्लिकेशन सर्वर के समान सर्वर पर रहता है।

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

संबंधपरक डेटाबेस आमतौर पर हुड के नीचे एक बी + पेड़ या एक संस्करण का उपयोग करते हैं और अक्सर कई रिकॉर्ड किए गए रिकॉर्ड्स के लिए डिस्क और बफर पूल पर डेटा संरेखण जैसे कई अनुकूलन होते हैं। यह उन्हें बड़े डेटासेट को जल्दी से संसाधित करने में उत्कृष्ट बनाता है, खासकर अगर एकत्रीकरण या फ़िल्टरिंग शामिल है।


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

@hulkmeister हाँ आमतौर पर, जब तक कि डेटासेट बहुत छोटा या डेटाबेस धीमे नेटवर्क पर आपके स्थान पर दूरस्थ न हो।
पीटर स्मिथ

0

डेटाबेस से आपका क्या अभिप्राय है? क्या आप MySQL, या SQL सर्वर जैसे एक रिलेशनल डेटाबेस का मतलब है? एक रिलेशनल डेटाबेस एक मेटा-डेटा संरचना है जो रिलेशनल मॉडल द्वारा परिभाषित संचालन के कुछ सबसेट का समर्थन करता है । संबंध मॉडल का सिद्धांत जो ज्यादातर 60 के दशक में एडगर कॉड द्वारा काम किया गया था।

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

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


क्षमा करें, बस अंतिम पैराग्राफ के संबंध में "बहुत थोड़ा सा सनक" का मतलब क्या है?
हुलकेमिस्टर

@hulkmeister, खेद है कि 'बड़ा' होना चाहिए था 'बिट' नहीं। संबंधपरक मॉडल बहुत सार और काफी जटिल है। एक कार्यान्वयन प्रदान करना जो वास्तव में पर्याप्त रूप से प्रदर्शन करता है, विशेष रूप से एक जो ACID प्रदान करता है (एटमॉसिटी, कंसिस्टेंसी, अलगाव, स्थायित्व) पर्दे के पीछे चलने वाले बहुत परिष्कृत कोड लेता है।
चार्ल्स ई। ग्रांट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.