गतिशील व्यवसाय ऑब्जेक्ट्स/डेटा संस्करण कैसे करें?

Question

हम एक बड़े अनुप्रयोग विकसित कर रहे हैं जो व्यापार से संबंधित हैं। आप इन अनुप्रयोगों को कुछ ईआरपी, सीआरएम, आदि के समान पा सकते हैं

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

उदाहरण के लिए: कुछ समय पर, उपयोगकर्ता को यह देखने की आवश्यकता होगी कि किसी विशेष खरीद आदेश का परिवर्तन इतिहास क्या है?

मैं एक बहुत ही सामान्य संस्करण हैंडलर (कठोर नहीं) की तलाश में हूं, जो कुछ व्यवसाय डेटा विशेषताओं को बदलने के मामले में भी मामलों को संभाल सकता है। यह एकल संस्करण हैंडलर किसी भी प्रकार की व्यावसायिक वस्तुओं/डेटा के साथ काम करने में सक्षम होना चाहिए।

इन्हें संभालने के लिए सबसे अच्छा प्रोग्रामिंग/डेटाबेस डिज़ाइन क्या होगा।

कोई विचार या राय?

पीएस: मैंने कुछ प्रोग्रामिंग टैग जोड़े हैं क्योंकि मैं प्रोग्रामर को इस धागे का मनोरंजन करने और उनके विचार देने के लिए चाहता हूं।

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

Answer 1

purely functional आलसी डेटा संरचनाओं को अपनाने का सही समय हो सकता है।

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

उदाहरण के लिए, आपके पास Order उदाहरण है जिसमें OrderItem एस की एक सूची है और आपको उस सूची में एक विशिष्ट OrderItem जोड़ने की आवश्यकता है।क्या आप इस मामले में क्या एक नई सूची, बारी में से cons 'नए OrderItem वर्ष सूची में ing बनाई गई है जिसके द्वारा की जगह अपने आइटम की सूची से Order का नया उदाहरण पैदा हो गई।

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

 
Address | Object    | Created by 
--------+--------------------+------------------------------------------ 
    1000 | list of OrderItems | empty list constructor 
    1001 | Order    | Order constructor, uses address 1000 
        ...   
    1300 | OrderItem   | ... 
    1501 | list of OrderItems | cons of addr 1300 to addr 1000 
    1502 | Order    | replace order_items in addr 1001 by addr 1501 

इस तरह से डेटा भंडारण के बहुत संरचना लगातार है (क्रिस ओकासाकी, his thesis में इस पर बताते हैं उदाहरण के लिए)। आप अपने निर्माण इतिहास का पालन करके किसी ऑब्जेक्ट के किसी भी संस्करण को पुनर्स्थापित कर सकते हैं; संस्करण छोटा हो जाता है। बस मुख्य बिंदु याद रखें: डेटा को म्यूटेट न करें, इसके बजाय नए उदाहरण बनाएं।

Answer 2

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

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

Answer 3

असल में आप किसी मौजूदा ऑब्जेक्ट और नई ऑब्जेक्ट के फ़ील्ड की तुलना करने और अंतर को बनाए रखने में सक्षम होना चाहिए।

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

Answer 4

Hibernate Envers की रेखाओं के साथ कुछ - एक इकाई लेखा परीक्षा समाधान, आपकी आवश्यकताओं के लिए एक उपयुक्त फिट प्रतीत होता है।

Answer 5

मुझे अतीत में ऐसा कुछ करना पड़ा है।

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

प्रभावशाली रूप से सूचकांक प्रश्न में ऑब्जेक्ट का संस्करण संख्या बन जाता है और नवीनतम संस्करण के लिए डीबी को कोई भी क्वेरी क्वालीफायर WHERE NextVersionIndex=0 का उपयोग करेगी।

यदि स्क्रैच से शुरू नहीं होता है तो इन मूल्यों को स्टोर करने के लिए अतिरिक्त तालिका जोड़कर इसे लाइव सिस्टम में लागू किया जा सकता है - ऑब्जेक्ट इंडेक्स, पिछला संस्करण अनुक्रमणिका, अगला संस्करण अनुक्रमणिका।