सूची डेटाबेस डिजाइन

Question

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

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

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

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

धन्यवाद

Answer 1

मैंने अपनी वर्तमान कंपनी में दोनों दृष्टिकोण देखे हैं और निश्चित रूप से पहले (स्टॉक लेनदेन के आधार पर गणना करने वाले कुल योग) की तरफ झुकेंगे।

यदि आप केवल किसी क्षेत्र में कुल मात्रा संग्रहित कर रहे हैं, तो आपको पता नहीं है कि आप उस नंबर पर कैसे पहुंचे। कोई लेनदेन इतिहास नहीं है और आप समस्याओं का सामना कर सकते हैं।

अंतिम प्रणाली मैंने प्रत्येक लेनदेन को सकारात्मक या नकारात्मक मात्रा के साथ रिकॉर्ड के रूप में संग्रहीत करके ट्रैक ट्रैक लिखा था। मैंने पाया है कि यह बहुत अच्छी तरह से काम करता है।

Answer 2

मैं पहली बार जिस तरह से करने के लिए चुनते हैं, हाथ पर मात्रा गणना की जाती है जहां

कुल सूची प्राप्त - सूची की कुल

सही रास्ता बेच दिया, IMO।

संपादित करें: मैं सिस्टम में किसी भी स्टॉक हानि/क्षति में कारक बनाना चाहता हूं, लेकिन मुझे यकीन है कि आपके पास यह कवर है।

Answer 3

यह निर्भर करता है, सूची प्रणाली केवल वस्तुओं की गणना करने से कहीं अधिक है। उदाहरण के लिए, लेखांकन उद्देश्यों के लिए, आपको फीफो (फर्स्ट-इन-फर्स्ट-आउट) मॉडल के आधार पर सूची के लेखांकन मूल्य को जानने की आवश्यकता हो सकती है। इसकी गणना "कुल सूची प्राप्त - कुल सूची बेची गई" सूत्र द्वारा गणना नहीं की जा सकती है। लेकिन उनका मॉडल इसकी आसानी से गणना कर सकता है, क्योंकि वे लेखांकन मूल्य को संशोधित करते समय संशोधित करते हैं। मैं विवरण में नहीं जाना चाहता क्योंकि यह प्रोग्रामिंग समस्या नहीं है, लेकिन अगर वे इसके द्वारा कसम खाता है, तो हो सकता है कि आप उन्हें अपनी सभी आवश्यकताओं को पूरी तरह समझ सकें।

Answer 4

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

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

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

Answer 5

मैं दो कॉलम रखने के लिए कुछ लाभ देख सकता हूं, लेकिन मैं विसंगतियों के बारे में कुछ हिस्सा नहीं देख रहा हूं - ऐसा लगता है कि दो कॉलम (इन और आउट) होने से एक कॉलम की तुलना में विसंगति कम होती है (वर्तमान)। ऐसा क्यों है?

Answer 6

दोनों परिस्थितियों के आधार पर मान्य हैं। पूर्व सबसे अच्छा है जब निम्नलिखित शर्तों पकड़:

• राशि के आइटम्स की संख्या अपेक्षाकृत छोटा है
• देखते हैं कुछ या कोई असाधारण मामलों पर विचार करने के (रिटर्न, समायोजन, एट अल)
• सूची आइटम मात्रा दूसरी ओर बहुत बार

की जरूरत नहीं है, यदि आप आइटम की एक बड़ी संख्या है, कई असाधारण मामलों, और बार-बार उपयोग किया है, यह आइटम मात्रा

+०१२३५१६४१०६१ बनाए रखने के लिए और अधिक कुशल हो जाएगा

भी ध्यान रखें कि यह कीड़े जो नीचे नज़र रखी जानी चाहिए और सफाया

मैं सिस्टम किया है दोनों तरीकों से, और दोनों तरीकों से ठीक काम कर सकते हैं अगर आपके सिस्टम फ़र्क तो है - जब तक आप को अनदेखा न करें के रूप में कीड़े!

Answer 7

मुझे लगता है कि यह वास्तव में एक (अपेक्षाकृत) महंगी गणना करने के बारे में एक सामान्य सर्वोत्तम प्रथा है, जब भी आपको कुल बनाम आवश्यकता होती है। हर बार कुछ बदलावों की गणना करते हैं, फिर एक क्षेत्र में गिनती संग्रहित करते हैं और उस क्षेत्र को पढ़ते हैं जब भी आपको कुल आवश्यकता होती है।

यदि मैं लेन-देन का उपयोग नहीं कर सका, तो हर बार जब मुझे कुल आवश्यकता होती है तो मैं लाइव गिनती के साथ जाऊंगा। यदि लेन-देन उपलब्ध हैं, तो इन्वेंट्री अपडेट ऑपरेशंस और फिर से गिनती कुल की बचत उसी लेनदेन के भीतर करना सुरक्षित होगा, जो गिनती की सटीकता सुनिश्चित करेगा (हालांकि मुझे यकीन नहीं है कि यह एकाधिक उपयोगकर्ताओं के साथ काम करेगा डेटाबेस मारना)।

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

Answer 8

एक या दो कॉलम, होने नहीं कर रहा है कि मैं क्या "योग सूची प्राप्त - सूची की कुल बिक्री" के साथ का मतलब कुछ इस तरह है:

Select sum(quantity) as inventory_received from Inventory_entry 
Select sum(quantity) as inventory_sold from Sales_items 

तो

Qunatity_on_hand = inventory_received - inventory_sold 

कृपया ध्यान रखें कि मैंने इसे और मेरे शुरुआती स्पष्टीकरण को बढ़ा दिया। मुझे पता है कि सूची में बहुत कुछ है कि मात्राओं का ट्रैक रखना, लेकिन इस मामले में समस्या झूठ है और हम क्या तय करना चाहते हैं। इस बिंदु पर इसे बदलने का कारण सटीक रूप से वर्तमान डिजाइन के कारण समस्याओं का समर्थन करने की लागत है।

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

अब तक आपके उत्तरों के लिए धन्यवाद।

नेल्सन Marmol

Answer 9

हम विभिन्न समस्याओं को हल, लेकिन उनमें से कुछ के प्रति हमारे दृष्टिकोण आप के लिए दिलचस्प हो सकता है।

हम सिस्टम को "सर्वश्रेष्ठ अनुमान" बनाने की अनुमति देते हैं, और उपयोगकर्ताओं को उन गलत अनुमानों के बारे में नियमित प्रतिक्रिया देते हैं जो गलत दिखते हैं। की तर्ज पर

inventory_received 
inventory_sold 
estimated_on_hand 

उसके बाद, आप एक प्रक्रिया पड़ सकते है:

सूची को यह लागू करने के लिए आप 3 क्षेत्रों हो सकता था (दैनिक?):

SELECT * 
FROM Inventory 
WHERE estimated_on_hand != inventory_received - inventory_sold 

बेशक, इस इस चेतावनी को देखते हुए उपयोगकर्ताओं पर निर्भर करता है, और इसके बारे में कुछ कर रहा है।

इसके अलावा, आप सूची को रीसेट करने के लिए एक फ़ंक्शन भी कर सकते हैं, या तो इन्वेंट्री_सॉल्ड/प्राप्त अपडेट करके, या शायद एक और फ़ील्ड "इन्वेंट्री_एड समायोजन" जोड़कर, जो सकारात्मक या नकारात्मक हो सकता है।

... बस कुछ विचार। उम्मीद है कि यह सहायक है।

Answer 10

• The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises
• The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries
• The Data Model Resource Book: Universal Patterns for Data Modeling

मैं खंड 1 है और खंड 2 और इन अतीत में बहुत मददगार रहे हैं।

Answer 11

ARTS (खुदरा प्रौद्योगिकी मानकों के लिए एसोसिएशन) डेटा मॉडल (http://nrf-arts.org) पर एक नज़र डालें। यह प्रत्येक आइटम के रिकॉर्ड के साथ स्टॉक लेजर तालिका का उपयोग करता है और सूची में परिवर्तन सभी इन्वेंटरी जर्नल एंटर्रीज़ में ट्रैक किए जाते हैं।

Answer 12

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

आप संभावित रूप से नकली प्रीकंप्यूटेड कॉलम (बहुत प्रभावी ढंग से ... मैं ट्रिगर्स का उपयोग करके) देख सकता हूं। हालांकि आपको शायद लेन-देन की आवश्यकता होगी। आईएमएचओ, जब आप इस तरह के नियंत्रित denormalization कर रहे हैं डेटा डेटा अखंडता रखते हुए एक ट्रिगर के लिए एकमात्र वैध उपयोग है।

Answer 13

Django-inventory निश्चित संपत्तियों के लिए अधिक तैयार किया गया है, लेकिन आपको कुछ विचार दे सकते हैं।

आईई: ItemTemplate (वर्ग) -> ItemsOnHand (उदाहरण)

ItemsOnHand अधिक ItemTemplates से जोड़ा जा सकता है; उदाहरण प्रिंटर & स्याही कारतूस की आवश्यकता है। यह प्रत्येक आइटमऑनहाण्ड के लिए रीडर पॉइंट सेट करने की अनुमति देता है।

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