पुनरावर्ती बिलिंग डेटाबेस डिजाइन

Question

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

तो मैं कैसे डेटाबेस (शायद एक डेटाबेस मुद्दा लेकिन एक प्रोग्रामिंग एक नहीं है) डिजाइन करने के लिए पर मेरे दिमाग जल रहा हूँ,

किसी भी एक आवेदन पत्र के इस प्रकार के लिए आते हैं है? क्या दृष्टिकोण लिया गया है?

Answer 1

मुझे लगता है कि आप इसे जटिल बना रहे हैं।

pk id_subscription 
fk id_user 
fl_type (maybe there are different subscriptions, with different prices) 
dt_in 
dt_out 

एक मेज भुगतान कई भुगतान करने के लिए एक सदस्यता बनाएँ::

pk id_payment 
fk id_subscription 
fl_type (card, payment order, something else) 
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc) 
dt_generated 
dt_sent 
dt_confirmed 
dt_canceled 
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model) 

pk id_user 
nm_user 
fl_status (active, canceled, pendent, etc) 

एक मेज सदस्यता कई सदस्यता के लिए एक उपयोगकर्ता बनाएँ:

एक मेज उपयोगकर्ता बनाएँ अब आपको कुछ रोबोट बनाने की आवश्यकता होगी जो हर विशिष्ट समय पर हर रोज चलेंगे।

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

एक रोबोट ऑर्डर के साथ एक ईमेल या कुछ भेज देगा (और तब ध्वज)।

एक और रोबोट आपके भुगतान मॉडल का उपयोग करके भुगतान की पुष्टि करेगा।

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

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

Answer 2

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

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

कभी-कभी सरल सबसे अच्छा होता है।