वित्तीय रिकॉर्ड रखने के लिए डेटाबेस डिजाइन करते समय क्या विशेष विचार आवश्यक हैं?

15

मुझे आशा है कि यह प्रश्न बहुत व्यापक नहीं है। भविष्य में मुझे कुछ अनुप्रयोगों (ज्यादातर वेब-आधारित अनुप्रयोगों के लिए कुछ लेखांकन और वित्तीय-ट्रैकिंग सिस्टम को जोड़ने की आवश्यकता हो सकती है, लेकिन मेरे प्रश्न डेस्कटॉप ऐप्स से भी संबंधित हैं)।

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

मुझे "डबल-एंट्री अकाउंटिंग" जैसे शब्द सुनने को मिलते हैं, और मुझे लगता है कि अधिकांश वित्तीय ट्रैकिंग ऐप्स (उदाहरण के लिए, Mint.com, या GnuCash) में डबल-सुनिश्चित करने के लिए बहुत अधिक जटिल डेटा संरचना या प्रक्रिया है। पूरी तरह से जोड़ता है, जैसा कि यह होना चाहिए, और यह कि कोई डेटा कभी भी खो या दूषित नहीं है।

मेरा प्रश्न है: वित्तीय लेनदेन को ट्रैक करने के लिए ऐप डिज़ाइन करते समय, क्या विशेष डिज़ाइन विचार किए जाने चाहिए? ऐसा लगता है कि बहुत सारे संभावित मुद्दे हो सकते हैं ... राउंडिंग सटीक, समता जाँच, किसी प्रकार की ऑडिट प्रक्रिया, विशेष बैकअप, सुरक्षा / एन्क्रिप्शन, क्रैश मिड डेटा-एंट्री के मामले में डेटा की सुरक्षा के अतिरिक्त तरीके। ... मैं वास्तव में नहीं जानता कि मुझे विशेष रूप से क्या पूछना चाहिए, लेकिन मुझे यह महसूस होता है कि प्रोग्रामिंग उद्योग में सर्वोत्तम प्रथाओं का एक सेट है जिसके बारे में मुझे कुछ भी नहीं पता है। वे क्या हैं?

संपादित करें:

ऐसा लग रहा है कि मैंने अपनी अपेक्षा से अधिक बड़े कीड़े खोले। स्पष्ट करने के लिए, मैं विशेष रूप से दो प्रकार के ऐप्स के बारे में सोच रहा हूं:

"रजिस्ट्री की जाँच करें" जैसे कि GnuCash या क्विक जैसी एप्स जो अपने स्वयं के उपयोग के लिए एक व्यक्ति के लेनदेन का रिकॉर्ड बनाए रखती हैं।
वे एप्लिकेशन जो किसी कंपनी के साथ सौदा करने वाले विक्रेताओं और ग्राहकों के लिए चालान / क्रेडिट / या "अंक" ट्रैक करते हैं।

मैं शायद कोई प्रत्यक्ष बैंकिंग या (AFAIK) कुछ भी नहीं कर रहा हूँ जिसमें वित्त से जुड़े सरकारी नियमों का एक टन है।

— जोशुआ कारमोडी
स्रोत

4

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

— शैतानिकप्‍पी

3

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

— माइक क्लार्क

@Satanicpuppy - अच्छा, क्या मैं एक नया GnuCash बनाना चाहता था? मैं एक बुनियादी लेनदेन या रजिस्ट्री का चालान कर रहा हूं। CC बिलिंग ऐप या स्टॉक-ट्रेडिंग ऐप जैसा कुछ भी नहीं है।

— जोशुआ कारमोडी

@ जोशुआ: कृपया इसे अपने प्रश्न में संपादित करें: "मैं एक मूल लेनदेन या चालान रजिस्ट्री के बारे में सोच रहा हूं। CC बिलिंग ऐप या स्टॉक-ट्रेडिंग ऐप जैसा कुछ भी नहीं है।" (आपने अपने प्रश्न के अंत में "वित्तीय सेवाओं" का उल्लेख किया है। लेखा और वित्तीय सेवाएं बिल्कुल समान नहीं हैं।)

— जुआन

2

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

— rwong

10

आपको इसके कई उत्तर मिलेंगे मुझे यकीन है, कई आदर्शवादी उत्तर भी हैं, मैं केवल अपने अनुभव से जवाब दे सकता हूं कि वित्तीय और वास्तव में क्या होता है।

आपने पहले ही अधिकांश मुद्दों को कवर कर लिया है।

राउंडिंग प्रिसिजन वास्तव में मेरे अनुभव में बहुत अधिक समस्या नहीं है। अधिकांश बड़े वित्तीय संगठन जो रातोंरात बड़े नहीं हुए (यानी हेज फंड को छोड़कर सब कुछ) विरासत अनुप्रयोगों की एक विशाल श्रृंखला है जो विभिन्न ईंधनों के कारण विभाजित हो गए हैं। वे लगातार सटीक गोलाई नहीं करते हैं; आम तौर पर एक निश्चित त्रुटि लाभ और नुकसान को केवल गोलाई के लिए स्वीकार किया जाता है। वास्तव में कई आदमी घंटे उन जगहों पर बिताए जाते हैं जहाँ मैंने काम किया है जहाँ मनुष्य जहाँ परम 'हाँ जो काफी करीब है' चयनकर्ताओं के लिए सटीक / अपेक्षित रकमों के मिलान की बात आती है। याद रखें, यह वास्तविकता पर आधारित एक उत्तर है, न कि क्या होना चाहिए।

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

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

ऑडिटिंग हर उस वित्तीय प्रणाली की कुंजी है, जिस पर मैंने कभी काम किया है। आपके पास 2 मूलभूत आवश्यकताएं हैं A) क्या आप डेटा में किए गए हर एक परिवर्तन को ट्रैक कर सकते हैं, किसके द्वारा, कब और क्यों? बी) क्या आप अपने डेटा की ऐतिहासिक स्थिति को साबित कर सकते हैं? यह छेड़छाड़ नहीं की गई है?

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

बी) एएमईएक्स बनाम वी विन्नी मामला देखें - जहां एएमएक्स उनके लिए 40k बकाया जमा करने में असमर्थ थे क्योंकि वे साबित नहीं कर सकते थे कि उनके रिकॉर्ड नहीं बने थे। आम तौर पर इसके लिए उपयोग किए जाने वाले समाधान को समय पर मुहर लगाने पर भरोसा किया जाता है। बड़े वित्तीयों के पास गारंटर बैंक होते हैं जो लेन-देन की गारंटी देते हैं और इस प्रकार स्वाभाविक रूप से विश्वसनीय समय की मोहर प्रदान करते हैं। जीवन के अन्य क्षेत्रों / परिदृश्यों के लिए इसके लिए वाणिज्यिक प्रदाता हैं।

— जोनो
स्रोत

6

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

लेकिन, आदेश में कि आपके ग्राहकों को इसका उपयोग करने की अनुमति है, आपको अपने स्थानीय कानूनों के अनुरूप बनाना होगा। कुछ चीजें जिनका मैंने सामना किया (जर्मनी में)

भंडारण मामले के लिए दस्तावेज़ प्रारूप , क्योंकि ऐसे कानून हैं जो व्यवसायों को 10 साल तक अपनी कागजी कार्रवाई रखनी चाहिए। 10 वर्षों में, शायद आपका कार्यक्रम अब उपलब्ध नहीं है। इसलिए, आपको दस्तावेजों को एक दीन / आईएसओ-प्रमाणित तरीके से संग्रहीत करना होगा (.pdf जर्मनी में पर्याप्त लगता है)
ऑडिट ट्रेल्स अक्सर आवश्यक होते हैं, उदाहरण के लिए आपको संशोधन तिथियों के साथ एक ही दस्तावेज़ के विभिन्न संस्करणों को प्रस्तुत करना पड़ सकता है।
स्टोरेज मामलों का स्थान , क्योंकि 'डेटासेंस' (गोपनीयता), जो भंडारण के देश में भिन्न हो सकता है। यह क्लाउड-आधारित सेवाओं को थोड़ा मुश्किल बना देता है।
कुछ दस्तावेजों को एक गैर-परस्पर तरीके से संग्रहीत किया जाना है । यह वास्तव में कैसे हासिल किया जाता है यह ज्यादातर कानूनी रूप से नाइटपैकिंग पर निर्भर करता है (एक कागज अपरिवर्तनीय है, एक सीडी परस्पर है, एक कार्यकर्ता द्वारा हस्ताक्षरित सीडी नहीं है)

आपको निश्चित रूप से एक वकील से संपर्क करना चाहिए, बारीकियों के लिए, या कम से कम ग्राहक के साथ साझेदारी में काम करना चाहिए।

— keppla
स्रोत

3

विश्वसनीयता कारक आश्चर्यजनक रूप से महत्वपूर्ण हो जाते हैं जब आप लोगों के पैसे के साथ काम कर रहे होते हैं। यदि ट्विटर एक ट्वीट खो देता है, तो यह बहुत बड़ी बात नहीं है; यदि आप किसी के क्रेडिट कार्ड से शुल्क लेते हैं, लेकिन अपना ऑर्डर खो देते हैं, तो आपके संगठन के किसी व्यक्ति को क्रोधित ग्राहक से मिलने वाला है। तो दो बातें: 1. आप नहीं चाहते हैं कि पहली जगह में ऐसा हो, लेकिन 2. यह अंततः होगा चाहे आप कितने भी सावधान क्यों न हों, इसलिए आप एक तरह की ऊर्जा को लॉगिंग और ट्रेसिंग तंत्र में लाना चाहते हैं। जो आपको वापस जाने में मदद करेगा और "खोया हुआ" क्रम ढूंढेगा और स्थिति को सही करेगा।

उदाहरण के लिए, क्रेडिट-कार्ड चार्ज, लेकिन यह क्या है, या यह किसका है, आदि सभी में कोई रिकॉर्ड नहीं है।

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

— mindcrime
स्रोत

3

[1] उपयोगकर्ताओं के लिए और आपके ऐप के लिए सुरक्षा तालिकाओं (आंतरिक DB उपयोगकर्ताओं के साथ भ्रमित न करें) का उपयोग करें। मॉड्यूल, रूप, वेबपृष्ठ:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

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

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

इस सुविधा को "वर्चुअल विलोपन" कहा जाता है। वास्तविक विलोपन को "भौतिक विलोपन" कहा जाता है।

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

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[४] कुछ मामलों में, मुद्रा या मुद्रा मूल्य परिणाम को प्रभावित कर सकते हैं, जब एक विवरण में कई रिकॉर्ड का उपयोग किया जाता है, और, एक एकल मूल्य में, आईएनए हेडर रिकॉर्ड में जोड़ा जाता है।

अधिकांश डेटाबेस ब्रांड इस दिन, मुद्रा या धन डेटा क्षेत्र का समर्थन करते हैं। इसका इस्तेमाल करें।

कुछ विशेष परिस्थितियों में, कुछ लोग उन्हें एक निश्चित फ्लोट मूल्य में संग्रहीत करते हैं जो कई दशमलव अंकों, ("दशमलव") या यहां तक कि स्ट्रिंग मानों का समर्थन करते हैं।

ये तकनीक इसकी दोधारी तलवार है। यदि आपके एप्लिकेशन को उस प्रकार के प्रिस्क्रिप्शन की आवश्यकता है, तो वेब पर खोज करें कि कैसे इसे ठीक से लागू किया जाए।

चीयर्स। [किटी के लिए एक खुला टूना दे सकते हैं, या अपवित्र को न भूलें]

— umlcat
स्रोत

2

आपने अपना प्रश्न टैग कर दिया है, securityलेकिन आप ज्यादातर स्थिरता और विश्वसनीयता के बारे में बात कर रहे हैं, इसलिए मैं समीकरण के उस हिस्से का उत्तर देने की कोशिश करूंगा:

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

— एरण गैलपरिन
स्रोत

2

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

सभी तालिकाओं में ट्रिगर होना चाहिए जो ऑडिट रिकॉर्ड बनाते हैं। आप धोखाधड़ी को रोकने के लिए देख रहे हैं और अगर यह निर्धारित करने के लिए होता है कि कार्रवाई किसने कब की।

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

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

— HLGEM
स्रोत

1

लेखांकन अक्सर सत्यापन के बारे में है। जब तक आप इसे याद रखते हैं और प्रत्येक इकाई के बीच संबंधों को समझते हैं, तब तक इसे गलत करने के लिए बहुत कठिन है।

मैं कई जाँचों को सूचीबद्ध करने की कोशिश करूँगा, लेकिन मैं हमेशा कुछ मिस करूँगा, उम्मीद है कि यह आपके लिए खुद की खुदाई शुरू करने के लिए पर्याप्त होगा।

कुल डेबिट == कुल क्रेडिट, यह सच है कि क्या आप खातों के ENTIRE सेट या अलगाव में सिर्फ एक लेनदेन के बारे में बात कर रहे हैं। यदि यह टैली नहीं है, तो आप कम से कम एक पोस्टिंग से चूक गए। यह कैसे जनरल लेजर खुद को संतुलित करता है।

लेखा प्राप्य (नियंत्रण खाते में शुद्ध डेबिट) == कुल बिल (सभी बिल योग्य राशि की कुल राशि) - कुल प्राप्त (प्राप्त सभी भुगतानों की कुल राशि)। यह एक उदाहरण है कि कैसे वास्तविक PHYSICAL और मूर्त दस्तावेज़ शर्तों में लेन-देन के योग सामान्य लेज़र (डबल प्रविष्टि) के साथ संतुलन होना चाहिए।

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

जैसा कि आप देख सकते हैं, हर लेन-देन, उप-बहीखाता, यहां तक कि स्टॉक, सीधे जनरल लेजर में संबंध।

यदि आप इकाई परीक्षण कर रहे हैं, तो परीक्षण को चलाने के लिए बहुत आसान है जो ये सुनिश्चित करते हैं कि हर बार जब आप लेन-देन करें / अपडेट करें, तब तक यह पता चले कि आपको क्या जाँचना है।

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

जब आप इसे विकसित कर रहे हैं, तो आप जितने अधिक चेक कर सकते हैं, आपके लिए कुछ गलत होने की संभावना उतनी ही कम होगी।

बीटीडब्ल्यू, जब आप गोलाई से निपटते हैं, तो तैरने के बजाय दशमलव के साथ जाने की कोशिश करें, यह आपको सड़क के नीचे बहुत सारे सिरदर्द से बचाएगा। : पी

— Permas
स्रोत