आदेश/चालान/भुगतान डेटाबेस मॉडलिंग

Question

मैं एक ई-कॉमर्स वेबसाइट इस परिदृश्य है कि डिजाइनिंग हूँ:

1. एक ग्राहक वस्तुओं की खरीद और एक आदेश बना सकते हैं।
2. आदेश में अज्ञात शुल्क हो सकता है जिसे ग्राहक के बाद जोड़ा जाएगा आइटम की कुल राशि का भुगतान करता है। यही है, ग्राहक पहले कुछ राशि चुकाता है। आदेश कुछ शुल्क जोड़ता है और कुल बदलता है। और ग्राहक अंतर के लिए फिर से भुगतान करता है। लेकिन दो (या अधिक) भुगतान एक ही क्रम से जुड़े होते हैं।
3. (वैकल्पिक) ग्राहक एकाधिक ऑर्डर के लिए एकल भुगतान सबमिट कर सकता है।

वर्तमान में, मैं एक Order तालिका है और OrderLineItem रों (सरलीकृत स्कीमा) प्रत्येक आदेश के कई शामिल हो सकते हैं:

Order 
===== 
customer 
line_items 
total 
status 

OrderLineItem 
============= 
price 
quantity 
order 
product 

एक भुगतान एक आदेश (सरलीकृत स्कीमा) से संबद्ध है:

Payment 
======= 
order 
payment_account 
total 
result 

वर्तमान कार्यान्वयन में एकल आदेश परिदृश्य के लिए एकाधिक भुगतानों का समर्थन करना बहुत मुश्किल लगता है। मुझे लगता है कि मुझे सिस्टम में अपरिवर्तनीय चालान पेश करना है, और भुगतान को ऑर्डर के बजाय चालान से जोड़ा जाना चाहिए। हालांकि, मुझे उपरोक्त परिदृश्य के लिए ऑर्डर/चालान/भुगतान मॉडलिंग के साथ कुछ मदद की आवश्यकता होगी। कुछ विशिष्ट प्रश्न मेरे पास है:

1. एक आदेश और चालान (जैसे दोनों वस्तुओं और योग है) मेरे लिए बहुत समान लग रहे हो। सामान्य ई-कॉमर्स सिस्टम में प्रमुख अंतर क्या है?
2. मुझे अपने परिदृश्य के लिए चालान कैसे मॉडल करना चाहिए? क्या मुझे के लिए OrderLineItem एस Order और InvoiceLineItem एस के लिए होना चाहिए?
3. कुछ प्रारंभिक विचार: मेरे पास एक निश्चित क्रम के साथ से जुड़े कई चालान होंगे। जब भी ऑर्डर कुल बदलता है, तो मेरे पास किसी भी तरह अंतर की गणना करने और ग्राहक को एक नया/अपरिवर्तनीय चालान भेजता है। फिर, ग्राहक भुगतान कर सकता है और भुगतान चालान से जुड़े होगा।

कुछ सलाह सुनना अच्छा लगेगा। बहुत सराहना की। धन्यवाद!

Answer 1

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

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

तालिकाओं के बीच संबंधों के बारे में सोचो: Order के रूप में इन अन्य तरीके से संदर्भित करते हैं lineItem रों पकड़ की जरूरत नहीं है अर्थात

Order 
===== 
orderId 
customerId 
status 

OrderLineItem 
============= 
orderLineItemId 
orderId 
product 
price 
quantity 

तो तुम OrderID पर तालिकाओं में शामिल होने के क्रम में देखने के लिए।वहाँ भी total कि में शामिल होने से की जाती है के रूप में स्टोर करने के लिए आवश्यकता नहीं है।

अपने डेटा को डुप्लिकेट न करने का प्रयास करें: आपका चालान orderLineItem एस का संदर्भ देगा, लेकिन क्रम में आवश्यक नहीं है। उदाहरण के लिए, ग्राहक ए और ए को ऑर्डर करता है, लेकिन बी स्टॉक से बाहर है।

invoice 
======= 
invoiceId 
status 

invoiceLineItem 
=============== 
invoiceId 
orderLineItemId 
quantity 

दूसरे शब्दों में आइटम के विवरण के लिए कोई आवश्यकता नहीं है: तो जैसे अपने चालान टेबल लग सकता है आप एक जहाज और एक चालान ए के लिए संदर्भ देता है orderLineItemId पैदा करते हैं। आप सोच रहे हो सकता है क्यों तुम सिर्फ orderLineItem मेज पर एक invoiceId न जोड़ें - कारण ग्राहक आइटम ए के 10 के आदेश हो सकता है, लेकिन आप केवल उन में से 8, जहाज अन्य दो बाद में एक चालान पर जाना होगा।

भुगतान आदेश के खिलाफ नहीं बने हैं, वे के चालानों के लिए कर रहे हैं। तो आपकी भुगतान तालिका invoiceId का संदर्भ लेनी चाहिए।

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