सी प्रोग्रामिंग फ़ाइल रीडिंग/राइटिंग तकनीक

Question

फाइल पढ़ने और लिखने के साथ प्रोग्राम बनाने का मेरा पहला समय है। असल में मैं सोच रहा हूं कि ऐसा करने पर सबसे अच्छी तकनीक क्या है। क्योंकि जब मैंने अपने सहपाठी के साथ अपने काम की तुलना की, तो हमारा तर्क एक-दूसरे से बहुत अलग है।

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

इस समस्या का समाधान मेरे पहले कार्यक्रम इसका मेनू खोलें, मैं सभी रिकॉर्ड के अंदर पढ़ सकते हैं और एक सरणी [] में सहेज है। ऐसा करने में, मैं सभी रिकॉर्डों में हेरफेर कर सकता था। उसके बाद उपयोगकर्ता प्रोग्राम से बाहर निकलने से पहले, मैं इसे उसी फ़ाइल पर सहेजता हूं और उस पर सभी रिकॉर्ड्स को ओवरराइट करता हूं।

मेरा सहपाठी का समाधान इस तरह है। जब वह एक रिकॉर्ड जोड़ती है, तो वह फ़ाइल तक पहुंचती है और डेटा जोड़ती है, जब वह एक रिकॉर्ड संपादित करती है, तो वह फ़ाइल तक पहुंचती है और विशेष रिकॉर्ड संपादित करती है, और जब वह रिकॉर्ड हटा देती है तो वह फाइल तक पहुंचती है और रिकॉर्ड हटा देती है। तो उसने जो भी काम किया उसके लिए उसने क्या किया, वह फाइल तक पहुंच रही है।

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

Answer 1

यह एक क्लासिक केस है जिसे आप प्रोग्रामिंग में समय और समय का सामना करेंगे: क्या मैं गति या स्मृति उपयोग के लिए अनुकूलित करता हूं?

और, ऐसे सभी conundrums की तरह, कोई "सही" उत्तर या सही समाधान नहीं है। दूसरे शब्दों में, आप और आपके सहपाठी दोनों समस्या के आपके समाधान में सही हैं।

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

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

और इसमें व्यापारिक झूठ है। महत्वपूर्ण बातों में से कुछ अपने आप को यहाँ पूछने के लिए कर रहे हैं:

1. डेटा सेट बहुत बड़ा है (या बहुत बड़ी बनने जा रहा) स्मृति में पूरी तरह से फिट करने के लिए (सामान्य विन्यास आप के साथ काम कर रहे होंगे में) है? यदि आप डेटा के आम तौर पर छोटे सेट से निपट रहे हैं, तो कंप्यूटर में अब पर्याप्त रैम है कि यह शायद इसके लायक है।

2. आपको डेटा तक पहुंचने में कितनी तेजी से आवश्यकता है? क्या वास्तविक समय का उपयोग महत्वपूर्ण है? क्या यह विशेष रूप से बड़ा या जटिल डेटा सेट है जो मांग पर हार्ड डिस्क से लोड करने में बहुत अधिक समय लेगा? आपके उपयोगकर्ता किस प्रकार के प्रदर्शन की अपेक्षा करते हैं?

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

4. क्या आपको विशेष परिस्थितियों की अनुमति देने की आवश्यकता है? कई उपयोगकर्ताओं द्वारा समवर्ती पहुंच जैसी चीजें आपके सभी डेटा को स्मृति में अधिक कठिन बना देती हैं। अन्य उपयोगकर्ता डेटा में पढ़ने में सक्षम कैसे होंगे जो केवल स्थानीय कंप्यूटर पर स्मृति में संग्रहीत है? एक सामान्य फ़ाइल साझा करना (शायद यहां तक ​​कि साझा सर्वर पर भी) शायद यहां जरूरी है।

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

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

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

Answer 2

आपका संस्करण (स्मृति में सभी रिकॉर्ड रखने) संभवत: तेजी से हो जाएगा। यह आवश्यक है कि यदि रिकॉर्ड गणना बढ़ती है तो आपके पास पर्याप्त स्मृति है। इसके साथ बुरी चीज यह है कि एक प्रोग्राम क्रैश या अनिश्चित निकास आपको सभी डेटा खो देता है क्योंकि इसे कभी भी फ़ाइल में सहेजा नहीं जाता था।

आपका सहपाठियों संस्करण के रूप में तेजी से नहीं होगा, के रूप में फ़ाइल कब सबसे तेजी से आप कर सकते हैं नहीं है। लेकिन इसे कम स्मृति की आवश्यकता होगी और दुर्घटनाओं पर अधिक सुरक्षित होगा क्योंकि अधिकांश डेटा पहले से ही फाइल में होंगे।

Answer 3

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

1. क्या इसे एकाधिक उपयोगकर्ताओं द्वारा समवर्ती रूप से एक्सेस करने की आवश्यकता है?
2. क्या इसे एकाधिक मशीनों से एक्सेस करने की आवश्यकता है?

जानकारी का एक महत्वपूर्ण राशि के संचय ऐसे MySQL, Postgres, Microsoft SQL सर्वर, SQLite, आदि के रूप में एक SQL- आधारित डाटाबेस, होगा के लिए सबसे आम विकल्प ये ज्यादातर अपने सहपाठी के समाधान तुम्हारा की तुलना में अधिक के समान है।

Answer 4

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

यदि आज के डेस्कटॉप कंप्यूटर पर यह एक छोटी व्यावहारिक समस्या थी, तो आप छोटे डेटा सेटों पर चलाने के लिए अपेक्षाकृत महत्वहीन समय के खिलाफ विभिन्न समाधान विकसित करने में व्यतीत समय पर भी विचार करना चाहेंगे।

इसके अलावा, आज मौजूदा डेटाबेस का उपयोग कर समस्या को हल करना बेहतर हो सकता है जो कि फाइल सिस्टम में अपना डेटाबेस बनाने के बजाय प्रासंगिक मुद्दों को संभालने में अच्छा है।

Answer 5

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

इससे आपके छात्र नोट्स एप्लिकेशन के मुकाबले समस्या अधिक जटिल हो जाती है, और डेटाबेस में सबसे अच्छा प्रतिनिधि (SQLite और TokyoCabinet कुछ हल्के वजन वाले होते हैं)। यदि आप डेटाबेस का उपयोग नहीं कर सकते हैं, तो सरल कार्यान्वयन के साथ जाएं। इसमें कम कीड़े होंगी, और जब आप डेटाबेस के साथ इसे बदलने के लिए समय आते हैं तो आप संलग्न नहीं होंगे। तो, स्मृति में पूरी फ़ाइल पढ़ने का आपका दृष्टिकोण सबसे अच्छा विकल्प की तरह लगता है।