एक दस्तावेज़/नोएसक्यूएल डेटाबेस बैलेंस शीट जमा करने के लिए एक अच्छा उम्मीदवार है?

Question

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

मैं इस उन मामलों में से एक है पर शक कर रहे थे वास्तव में एक SQL डेटाबेस है सही फिट और जाने के लिए NoSQL गलती है की कोशिश कर रहा है, लेकिन फिर जब मैं क्या छोटे मैं CQRS और घटना सोर्सिंग के बारे में पता के बारे में सोच, मुझे आश्चर्य है यदि इकाई/दस्तावेज वास्तव में खाता है, और लेन-देन ईवेंट इसके खिलाफ संग्रहीत हैं, और जब ये "ईवेंट" होते हैं, तो शायद मेरा एप्लिकेशन SQL डेटाबेस जैसे आसानी से पूछे जाने योग्य पढ़ने की दुकान पर भी लिखता है।

अग्रिम में बहुत धन्यवाद।

Answer 1

इस मामले में, एक संबंधपरक डेटाबेस, सबसे उपयुक्त है जब से तुम संबंधपरक डेटा (जैसे। पंक्तियों और स्तंभों)

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

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

यदि यह मेरी निजी पालतू परियोजना थी, और मैं एक नई-आईएसएच तकनीक के बारे में और जानना चाहता था और देखता हूं कि यह किसी विशेष डोमेन में काम करता है, तो मैं जो भी दिलचस्प पाया और साथ ही यह काम नहीं करता बहुत अच्छा, तो मैंने कुछ सीखा। लेकिन, आपका लाभ भिन्न हो सकता है। :)

Answer 2

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

Answer 3

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

घटना सोर्सिंग और लेखा में एक ही सिद्धांत पर आधारित हैं:

यहाँ क्यों है। आप कुछ भी नहीं हटाते हैं, आप केवल संशोधित करते हैं। यदि आप एक लेनदेन जोड़ते हैं जो गलत है, तो आप इसे हटा नहीं देते हैं। आप ऑफ़सेट लेनदेन बनाते हैं। घटनाओं के साथ वही बात, आप उन्हें हटा नहीं देते हैं, आप बस एक ऐसा ईवेंट बनाते हैं जो पहले को रद्द कर देता है। इसका मतलब है कि आप बहुत सारे TransactionAddedEvent प्रकाशित कर रहे हैं।

अगला, यदि आप डबल एंट्री एकाउंटिंग कर रहे हैं, तो लेनदेन रिकॉर्ड करना स्क्रीन पर देखने के तरीके से अलग है (विशेष रूप से बैलेंस शीट में)। इसलिए, मुझे फिर से cqrs के लिए पसंद है।हम सही लेखांकन सिद्धांतों का उपयोग करके डेटा स्टोर कर सकते हैं, लेकिन हमारे पढ़ने के मॉडल को डेटा को दिखाने के तरीके को अनुकूलित करने के लिए अनुकूलित किया जा सकता है।

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

तो आपके दस्तावेज़ डीबी में आपके पास एक प्रविष्टि संग्रह होगा।

यह पूछताछ बहुत आसान बनाता है। यदि आप किसी खाते के लिए सभी प्रविष्टियों को देखना चाहते हैं तो आप केवल खाते से चुनें * खाता आईडी = 1. मुझे पता है कि यह एसक्यूएल है लेकिन हर कोई इस क्वेरी की सादगी को समझता है। यह एक दस्तावेज़ डीबी में बस इतना आसान है। इसके अलावा, यह तेजी से बिजली होगी।

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

Answer 4

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

इसे एक स्तरित वास्तुकला की तरह सोचें - स्रोत दस्तावेज़, असंतुलित रिकॉर्ड, संतुलित लेनदेन, फिर वित्तीय विवरण।

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

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