फ़ाइल प्रसंस्करण को डिजाइन करना जो कई फ़ाइल स्वरूपों, पार्सिंग, सत्यापन और दृढ़ता को नियंत्रित करता है

Question

यदि आपको फ़ाइल प्रोसेसिंग घटक/सिस्टम डिज़ाइन करना था, जो फ़ाइल प्रारूपों (एक्सेल जैसे स्वामित्व प्रारूपों सहित) में भिन्नता ले सकता है, पार्स/इस जानकारी को एक डीबी को मान्य और स्टोर करें .. आप इसे कैसे करेंगे?

नोट: इनपुट डेटा की 1 पंक्ति का 95% डेटाबेस में एक रिकॉर्ड के बराबर होगा, लेकिन हमेशा नहीं।

वर्तमान में मैं कुछ कस्टम सॉफ़्टवेयर का उपयोग कर रहा हूं जिसे मैंने अपने डेटाबेस में ग्राहक डेटा को पार्स/मान्य/स्टोर करने के लिए डिज़ाइन किया है। सिस्टम फ़ाइल सिस्टम (एक FTP ड्रॉप से) में स्थान द्वारा फ़ाइल की पहचान करता है और फिर एक एक्सएमएल "परिभाषा" फ़ाइल लोड करता है। (सही एक्सएमएल लोड किया गया है जहां इनपुट फ़ाइल को छोड़ दिया गया था)।

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

  <delimiter><![CDATA[ ]]></delimiter> 
    <numberOfItems>12</numberOfItems> 
    <dataItems> 
    <item> 
    <name>Member ID</name> 
    <type>any</type> 
    <minLength>0</minLength> 
    <maxLength>0</maxLength> 
    <validate>false</validate> 
    <customValidation/> 
    <dbColumn>MembershipID</dbColumn> 
    </item> 

क्योंकि इस डिजाइन इनपुट फ़ाइलें पाठ (निश्चित चौड़ाई या सीमांकित) हो सकता है और एक 1 1 के लिए डीबी स्तंभ के लिए इनपुट फ़ाइल डेटा क्षेत्र से संबंध होना आवश्यक है की

।

मैं Excel, या अन्य फ़ाइल स्वरूपों में लेने के लिए हमारी फ़ाइल प्रसंस्करण प्रणाली की क्षमताओं का विस्तार करना चाहता हूं।

कम से कम आधे दर्जन तरीके हैं जो मैं आगे बढ़ सकता हूं लेकिन मैं अभी अटक गया हूं क्योंकि मेरे पास वास्तव में विचारों को उछालने के लिए कोई भी नहीं है।

दोबारा: यदि आपको एक फ़ाइल प्रोसेसिंग घटक डिज़ाइन करना था, जो कि विभिन्न प्रकार के फ़ाइल स्वरूपों (एक्सेल जैसे मालिकाना प्रारूप सहित) ले सकता है, तो इस जानकारी को डीबी में सुरक्षित/मान्य करें और स्टोर करें .. आप कैसे होंगे कर दो?

Answer 1

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

Answer 2

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

हालांकि इस तरह विचार विमर्श प्रौद्योगिकी नास्तिक होना चाहिए, मुझे लगता है कि आप शायद पाएंगे कि जो Java और नेट शिविरों बहुत ज्यादा पूरा नहीं करते। मैं The Server Side पर देखता हूं लेकिन मैं जावा करता हूं और इसलिए जावा सामान की तलाश करता हूं।

Answer 3

ठीक है, एक सरल डिजाइन कुछ की तरह है ...

+-----------+ 
| reader1 | 
|   |--- 
+-----------+ \--- 
        \--- +----------------+    +-------------+ 
         \--| validation |    | DB   | 
         /---|    |---------------|    | 
+-----------+ /----- +----------------+    +-------------+ 
| reader2 |---- 
|   | 
+-----------+ 

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

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

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