2010-12-11 22 views
15

लेन-देन प्रविष्टि को डबल प्रविष्टि एकाउंटिंग डेटाबेस में संग्रहीत करना।डेटाबेस डिज़ाइन: लेखांकन लेनदेन तालिका

मैं दो समाधान विकल्प 1 और विकल्प 2 के साथ आया, मुझे बताया गया कि अधिकांश बैंकिंग पैकेज उनके डेटाबेस डिज़ाइन के लिए विकल्प 2 चुनता है। हालांकि मैं विकल्प 2 पर विकल्प 1 पसंद करता हूं क्योंकि यह केवल समझ में आता है और यह अधिक कुशल है!

I.e धन के 2 आंदोलन के लिए, विकल्प 1 के लिए 2 रिकॉर्ड बनाम विकल्प 2 के लिए 4 रिकॉर्ड की आवश्यकता है।

मैं जानना चाहता हूं कि बैंक विकल्प 1 पर विकल्प 2 क्यों चुनता है? इसका कारण क्या है?

Option 1) 
TRANSACTION 
Credit_AccountId 
Debit_AccountId 
Amount 
... 

Option 2) 
TRANSACTION 
AccountId 
Amount 
... 

उत्तर

17

विकल्प 1 संभावित रूप से एक सम्मिलित परिप्रेक्ष्य से थोड़ा अधिक कुशल होगा। लेकिन चूंकि बहुत सारे लेखांकन लेनदेन दो से अधिक खातों को प्रभावित करने जा रहे हैं, इसलिए लाभ 2: 1 से काफी कम होने की संभावना है।

विकल्प 2 इन जटिल लेनदेन के लिए स्पष्ट होगा। यही कारण है, एक लेखाकार सामान्य रूप से तीन पंक्तियों

  • डेबिट मिलेगा एक $ 100
  • क्रेडिट बी $ 60
  • क्रेडिट C $ 40

दो पंक्तियों

  • डेबिट एक की तुलना में अधिक स्पष्ट $ 60 क्रेडिट बी $ 60
  • डेबिट ए $ 40 क्रेडिट सी $ 40

यदि आपके पास दोनों तरफ से कई खाते हैं, तो यह थोड़ा अस्पष्ट होगा कि डेबिट और क्रेडिट को एक खाते में कैसे मिलान किया जाए। यही कारण है,

  • डेबिट एक $ 100
  • डेबिट बी $ 30
  • क्रेडिट सी $ 60
  • क्रेडिट डी $ 70

रूप

  • डेबिट निरूपित किया जा सकता एक $ 60 क्रेडिट सी $ 60
  • डेबिट ए $ 40 क्रेडिट डी $ 40
  • डेबिट बी $ 30 क्रेडिट डी $ 30

लेकिन वहां भी डाटा मॉडल 2.

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

+0

धन्यवाद, मैं जटिल लेनदेन के बारे में आपका बिंदु देख सकता हूं। – 001

+0

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

+0

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

5

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

+0

यह एक अच्छा तरीका है, लेकिन यह अपर्याप्त है क्योंकि लेखांकन के लिए कोई डिफ़ॉल्ट मॉडल नहीं है। – B4NZ41

संबंधित मुद्दे