विचारधारा और विकासशील वित्तीय प्रणालियों की समस्याएं। भाग २

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



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



एक उदाहरण पर विचार करें।

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



1. अद्वितीय संख्या

2. निर्माण की तिथि और समय

3. भुगतान की तारीख और समय

4. कानूनी इकाई (प्रतिपक्ष) जिसे भुगतान किया गया था

5. राशि

6. भुगतान का प्रकार



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

लेकिन वापस हमारे उदाहरण पर। क्षेत्र संख्या 4 - कानूनी इकाई पर ध्यान दें। जैसे ही हमारे पास कानूनी संस्थाओं की निर्देशिका होती है, इस क्षेत्र में इस निर्देशिका में प्रविष्टि के लिए लिंक रिकॉर्ड करना स्पष्ट है।

अब कुछ संभावित स्थितियों की कल्पना करें:

1) 2009 में एक भुगतान आदेश बनाया गया था। भुगतान बेड द्वारा किया गया था। जनवरी 2010 में, कंपनी का नाम बदलकर चेयर एलएलसी कर दिया गया। यह पता चला है कि यदि हम 2010 के अंत में भुगतान आदेश फॉर्म खोलते हैं, तो हम देखेंगे कि भुगतान एक कंपनी को किया गया था जो 2009 में भौतिक रूप से मौजूद नहीं था।

2) मान लीजिए कि मार्च 2010 में एलएलसी "बेड" और सीजेएससी "सोफा" का विलय हुआ, जिसका परिणाम ओजेएससी "सोफा एंड बेड" था। उपयोगकर्ता क्या कर सकते हैं? और वे OJSC "सोफा और बेड" में कंपनी LLC "बेड" का नाम बदल सकते हैं, और वे "सोफा बेड" में ZAO "सोफा" का भी नाम बदल सकते हैं। सबसे दिलचस्प बात पहली रिपोर्ट पर शुरू होगी, जब यह पता चलता है कि विभिन्न कानूनी संस्थाओं (डेटाबेस में 3 वास्तविक और 4) के बीच सभी भुगतान मिलाए गए थे और केवल भुगतान करने वाले लोग ही उन्हें अलग कर सकते थे (जो, दुर्भाग्य से, कर्मचारियों की कमी के तहत गिर गए थे और पहले ही कई महीने हो गए थे अपनी कंपनी में काम नहीं करते)।





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



और यह सब मौलिक रूप से गलत है:

a) आप उन कार्यों के लिए ज़िम्मेदारी लेते हैं जिन्हें आप बिल्कुल भी करने के हकदार नहीं हैं;

बी) ऐसी स्थितियां हैं, जो सिद्धांत रूप में, बाहर नहीं की जा सकती हैं;

ग) यह प्रणाली में एक स्पष्ट गलती है, जिसकी घटना की आपने भविष्यवाणी नहीं की थी।



तो, मैं उस बारे में बात करने के लिए जाना चाहता था।

दस्तावेजों से संबंधित डिजाइनिंग संस्थाएं।

हम कई आवश्यकताओं को सामने रखते हैं:

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

2. दस्तावेज़ों को व्यवसाय प्रक्रिया में वर्णित किसी भी तर्क का सामना करना होगा। वर्णित उदाहरण में, इसका मतलब है कि यदि आपको सभी कानूनी संस्थाओं के लिए सभी भुगतान आदेशों की राशि का योग करने की आवश्यकता है, जिनके पास एक अलग नाम है, तो आपके पास ऐसा करने की तकनीकी क्षमता होगी।



जहां तक ​​मेरा अनुभव मुझे (मॉस्को सिटी हॉल सिस्टम से शुभकामनाएं) देता है, मैं कह सकता हूं कि लगभग सभी को पहला पैराग्राफ याद है, लेकिन लगभग किसी को पैरा 2 याद नहीं है। यानी यह आमतौर पर निम्नानुसार लागू किया जाता है: दस्तावेज़ के सभी फ़ील्ड (आमतौर पर उन सभी फ़ील्ड जो दस्तावेज़ के मुद्रित रूप में आते हैं) को डेटाबेस तालिका में एक पाठ तालिका में संग्रहीत किया जाता है। हमारे उदाहरण में, इसका मतलब है कि कंपनी के संदर्भ के अलावा, इस कंपनी का नाम भी तालिका में संग्रहीत है।

यह निश्चित रूप से कुछ समस्याओं को खत्म करता है, लेकिन उन सभी को नहीं। और सामान्य तौर पर, यह वैचारिक रूप से गलत है: लिंक एक नाम के साथ एक कंपनी को संग्रहीत किया जाता है, और दूसरा भुगतान आदेश में प्रदर्शित किया जाता है (यह है कि कंपनी का नाम बदल दिया गया था)।

हमने इस समस्या को कैसे हल किया

हमने दो विकल्पों पर विचार किया:



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

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

इसके अलावा, चूंकि हमारे रिकॉर्ड संस्करणों की तालिका में अलग-अलग आईडी हैं, इसलिए उनके द्वारा सारांशित (समूह / वर्गीकृत / साझा) करना खुशी की बात है।



2. कानूनी संस्थाओं की निर्देशिका में दो तालिकाएँ हैं।

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

दूसरे में इस इकाई के सभी क्षेत्र शामिल हैं, साथ ही साथ मूल तालिका में रिकॉर्ड और नए रिकॉर्ड बनाने का समय भी शामिल है।

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



नतीजतन, दूसरा विकल्प चुना गया था। और यहाँ क्यों है:

1. मूल आइटम का एक सामान्य संदर्भ पहले विकल्प के सभी फायदे छोड़ देता है (हम अभी भी आसानी से सभी रिकॉर्डिंग विकल्पों को अपने अस्थायी संशोधनों में विभाजित कर सकते हैं और व्यक्तिगत रूप से काम कर सकते हैं), लेकिन मूल रिकॉर्ड के सभी संस्करणों के साथ काम करने में कोई कठिनाई नहीं होती है।

2. MS SQL: चूंकि पहले मामले में, निम्नलिखित संशोधन पिछले एक को संदर्भित करता है (यानी NULL <- ver1 <- ver2 <- ver3 <- ... <- verN), फिर

a) परिवर्तनों के पूरे इतिहास को देखने के लिए, हमें ith नोड से बाईं ओर और दाईं ओर श्रृंखला को बायपास करना होगा, जिसके लिए डेटाबेस स्तर पर कुछ खर्चों की आवश्यकता होगी। और यह एक परमाणु कार्य है जो केवल रिकॉर्ड में परिवर्तन के बारे में जानकारी देता है।

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

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



मुझे लगता है कि यह दूसरे भाग के लिए पर्याप्त है।

मुझे आपके सभी सवालों के जवाब देने में खुशी होगी।