कई भुगतान गेटवे को संभालने के लिए स्कीमा डिजाइनिंग


9

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

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

मुझे यकीन नहीं है कि यह करने का अधिक इष्टतम तरीका है। भविष्य में आने वाले समान परिदृश्यों के लिए भी इसे सीखने की जरूरत है।


यह आपकी सटीक स्थिति पर निर्भर करता है। सामान्य तौर पर, एक बड़ी तालिका के सबसेट का चयन करना सस्ता होता है, जिसमें कई छोटी-छोटी तालिकाओं को एक साथ मिलाने पर UNION के साथ विलय हो जाता है। लेकिन ऐसी परिस्थितियां हैं जहां छोटे तालिकाओं के डिजाइन बेहतर काम करते हैं।
वाल्टर मिती

आपके पास अब तक क्या है?
हारून

@ BryceAtNetwork23 अभी के लिए, मैं दो पीजी संभाल रहा हूं और मेरे पास उन दोनों के लिए अलग-अलग टेबल हैं। लेकिन मुझे भविष्य में और पीजी जोड़ना होगा। तो सोच रहा था कि क्या मुझे ऐसा करना जारी रखना चाहिए, क्योंकि मुझे हर बार अधिक तालिकाओं को जोड़ना पड़ता है। स्तंभों और रिकॉर्ड की बढ़ती संख्या के साथ तालिकाओं की बढ़ती संख्या और एक तालिका के बीच इसका विकल्प। मैं थोड़ा उलझन में हूँ।
बिबह्स

@ भाई, क्या आपके द्वारा उपयोग किए गए समाधान को हमारे साथ साझा करना संभव है? मुझे भी यही शक हो रहा है।
मार्सिओ माजुकाटो

@MarcioSimao हम एकल तालिका के साथ गए जैसे गुण paypal_transaction_id, bank_transaction_idआदि। हमारे पास बहुत अधिक भुगतान गेटवे नहीं थे, इसलिए इसने हमारे लिए काम किया। कई पीजी का समर्थन करने वालों के साथ काम नहीं कर सकते हैं।
बिबस

जवाबों:


7

यह इस बात पर निर्भर करता है कि भुगतान प्रकारों के बीच डेटा कितना अलग है।

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

यदि आपके डेटा में बहुत सारे अलग-अलग फ़ील्ड हैं, तो आप प्रत्येक भुगतान गेटवे के लिए अलग-अलग तालिकाओं के साथ एक मास्टर लेनदेन तालिका आज़मा सकते हैं। प्रत्येक भुगतान गेटवे प्रकार तालिका में लेन-देन की एक विदेशी कुंजी होगी, जो मास्टर लेन-देन तालिका में वापस जुड़ी होगी।

दूसरी ओर यदि आपके पेमेंट गेटवे के प्रकारों में सभी समान फ़ील्ड हैं, तो मैं एक लेन-देन तालिका के साथ रहना चाहूंगा।


1
इसे साफ करने के लिए धन्यवाद। मुझे लगता है कि यह मेरे सामने सही था, लेकिन इसे इंगित करने के लिए बस किसी की जरूरत थी। :)
बीभास

@ BryceAtNetwork23, अगर मेरे पास कई गेटवे हैं, जैसे कि 5 या अधिक, तो क्या आपको लगता है कि मुझे डेटा प्राप्त करने में कठिनाइयाँ होंगी? मैं यह इसलिए पूछ रहा हूं क्योंकि मुझे लगता है कि मास्टर ट्रांजेक्शन टेबल को प्रत्येक पेमेंट गेटवे टाइप में कई लेफ्ट जॉइन करने होंगे।
मार्सियो माजुकाटो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.