एक सास सदस्यता डेटा मॉडल

सास (एक सेवा के रूप में सॉफ्टवेयर) क्लाउड कंप्यूटिंग के तीन मुख्य घटकों में से एक है। आमतौर पर, SaaS एप्लिकेशन वेब-आधारित होते हैं और एक समय में कई अलग-अलग उपयोगकर्ताओं को संभाल सकते हैं। सदस्यता-आधारित समाधान बहुत लोकप्रिय SaaS प्रसाद हैं। कुछ प्रसिद्ध सास उत्पादों में माइक्रोसॉफ्ट ऑफिस 365, अमेज़ॅन वेब सर्विसेज (एडब्ल्यूएस), स्लैक, जीरा, स्ट्राइप और (बेशक) वर्टाबेलो शामिल हैं! आज हम एक डेटा मॉडल पर एक नज़र डालेंगे जो हमें SaaS सब्सक्रिप्शन प्रबंधित करने की अनुमति देगा।

विचार

सास उत्पाद बहुत भिन्न हो सकते हैं। कुछ नियमित रूप से उनकी सेवाओं के लिए शुल्क लेते हैं, उदा। मासिक या वार्षिक; अन्य केवल उपयोग किए गए समय या संसाधनों (या इन दोनों के संयोजन) के लिए शुल्क लेते हैं। इस लेख में चीजों को सरल रखने के लिए, मैं केवल मासिक भुगतान की गई सदस्यताओं पर ध्यान केंद्रित करूंगा।

आइए मान लें कि हमारे पास कुछ अलग सास समाधान हैं और हमें अपने सभी ग्राहकों को एक डेटाबेस में ट्रैक करने की आवश्यकता है। ऐसा तब हो सकता है जब हम डेटाबेस समाधान (जैसे Amazon DynamoDB), एनालिटिक्स टूल (जैसे Amazon Athena), या रोबोटिक्स एप्लिकेशन (जैसे AWS रोबोमेकर) प्रदान कर रहे हों। वास्तव में, अगर हम अमेज़ॅन को देखें, तो हम देख सकते हैं कि कई अलग-अलग एप्लिकेशन उपलब्ध हैं। हम केवल उन्हीं को चुनेंगे जिनकी हमें वास्तव में आवश्यकता है।

डेटा मॉडल

मॉडल में तीन विषय क्षेत्र होते हैं:

Users & groups
Software & plans
Subscriptions, plans & payments.

हम इनमें से प्रत्येक विषय क्षेत्र का वर्णन उनके सूचीबद्ध क्रम में करेंगे।

अनुभाग 1:उपयोगकर्ता और समूह

Users & groups विषय क्षेत्र हमारे आवेदन के सभी उपयोगकर्ताओं के बारे में जानकारी संग्रहीत करता है। हम मान लेंगे कि उपयोगकर्ताओं को समूहीकृत किया जा सकता है, उदा. जब कोई कंपनी कई कर्मचारियों के लिए लाइसेंस खरीदना चाहती है। हम एक समूह तब भी बनाएंगे, जब उसका केवल एक उपयोगकर्ता ही होगा। यह हमें बाद में उस समूह में नए सदस्यों को जोड़ने की सुविधा देगा।

यहां सबसे महत्वपूर्ण तालिका है user_account टेबल। हम इसका उपयोग उपयोगकर्ता खातों से संबंधित सभी विवरणों को संग्रहीत करने के लिए करेंगे। ये हैं:

first_name & last_name - उपयोगकर्ता का पहला और अंतिम नाम। कृपया ध्यान दें कि यहां संग्रहीत प्रत्येक उपयोगकर्ता एक निजी व्यक्ति है।
user_name - एक उपयोगकर्ता नाम (उपयोगकर्ता द्वारा चुना गया)।
password - उपयोगकर्ता के पासवर्ड का हैश मान। (उपयोगकर्ता अपने स्वयं के पासवर्ड सेट करते हैं।)
email - उपयोगकर्ता का ईमेल पता, पंजीकरण प्रक्रिया के दौरान सेट किया गया।
confirmation_code - ईमेल पुष्टिकरण प्रक्रिया के दौरान प्रयुक्त कोड।
confirmation_time - जब पंजीकरण/पुष्टिकरण पूरा हो गया था।
insert_ts - टाइमस्टैम्प जब यह रिकॉर्ड शुरू में डाला गया था।

उपयोगकर्ता समूह बना सकते हैं; समूहों में पूर्वनिर्धारित प्रकार होते हैं। सभी संभावित समूह प्रकारों की सूची user_group_type टेबल। प्रत्येक प्रकार को उसके type_name . द्वारा अद्वितीय रूप से परिभाषित किया गया है . हम प्रत्येक समूह प्रकार के लिए अनुमत समूह सदस्यों की न्यूनतम और अधिकतम संख्या को भी परिभाषित करेंगे। उस श्रेणी को दो मानों के साथ परिभाषित किया गया है - members_min (निचली सीमा) और members_max (ऊपरी सीमा)।

नया अकाउंट बनाते समय यूजर्स अपने यूजर ग्रुप का भी चयन करेंगे। यह user_group तालिका चयनित समूह प्रकार को संदर्भित करती है और टाइमस्टैम्प को संग्रहीत करती है (insert_ts ) जब यह रिकॉर्ड डाला गया था। customer_invoice_data विशेषता उस उपयोगकर्ता समूह के इनवॉइस पर हम क्या प्रिंट करेंगे, इसका एक टेक्स्ट विवरण है।

इस विषय क्षेत्र में अंतिम तालिका in_group टेबल। प्रत्येक समूह के लिए, हम उसके सभी सदस्यों की एक सूची संग्रहीत करेंगे। उपयोगकर्ता समूह के संदर्भ के अलावा (user_group_id ) और उपयोगकर्ता खाता (user_account_id ), हम उस टाइमस्टैम्प को भी स्टोर करेंगे जब उपयोगकर्ता को समूह में जोड़ा गया था (time_added ) या समूह से हटा दिया गया (time_removed , जिसमें केवल एक मान होगा यदि उपयोगकर्ता को हटा दिया गया है)। यदि उपयोगकर्ता group_admin . है, तो यह दर्शाने के लिए हमारे पास एक फ़्लैग भी होगा या नहीं। ग्रुप एडमिन ग्रुप के सदस्यों को अपडेट कर सकते हैं और नए सदस्यों को जोड़ सकते हैं।

अनुभाग 2:सॉफ़्टवेयर और योजनाएं

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

हम software टेबल। इस शब्दकोश में, हम अपने सभी SaaS प्रसादों की एक सूची संग्रहित करेंगे। प्रत्येक के लिए, हम स्टोर करेंगे:

software_name - एक अद्वितीय सॉफ्टवेयर नाम।
details - उस सॉफ़्टवेयर का वर्णन करने वाले सभी विवरण।
access_link - एक स्थान या लिंक जहां हम उस सॉफ़्टवेयर तक पहुंच सकते हैं।

हमें एक या अधिक विभिन्न योजनाओं में अपने सास समाधान पेश करने में सक्षम होना चाहिए। प्रत्येक योजना में विभिन्न विकल्प होते हैं। उदाहरण के लिए, हमारे पास एक प्रीमियम योजना हो सकती है जिसमें हमारे द्वारा प्रदान किए जाने वाले सभी विकल्प शामिल हों और एक मूल योजना जिसमें केवल आवश्यक शामिल हों। हम सभी विशिष्ट योजनाओं को plan टेबल। प्रत्येक योजना के लिए, हम परिभाषित करेंगे:

plan_name - इस प्लान के लिए हमने जो नाम चुना है। सॉफ्टवेयर के संदर्भ के साथ (software_id ), यह इस तालिका की वैकल्पिक/अद्वितीय कुंजी बनाता है।
user_group_type_id - इस योजना का उपयोग करने वाले समूह के प्रकार को दर्शाने वाला एक संदर्भ। यह एकल-उपयोगकर्ता समूह या मानक समूह हो सकता है। यह संदर्भ उस योजना के लिए समूह के सदस्यों की अधिकतम संख्या को भी परिभाषित करता है - उदा। यदि हमारी योजना एक सदस्यता पर पांच अलग-अलग खातों की अनुमति देती है, तो हमें उपयुक्त user_group_type . का संदर्भ देना चाहिए ।
current_price - इस प्लान की मौजूदा कीमत।
insert_ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।
active - एक झंडा यह दर्शाता है कि यह योजना सक्रिय है या नहीं।

हमने पहले ही उल्लेख किया है कि एक ही सॉफ्टवेयर के प्लान अलग-अलग विकल्पों के साथ आएंगे। सभी अलग-अलग विकल्पों की सूची option शब्दकोश। प्रत्येक विकल्प को उसके option_name . द्वारा अद्वितीय रूप से परिभाषित किया गया है ।

विभिन्न योजनाओं के लिए विकल्प निर्दिष्ट करने के लिए, हम option_included टेबल। यह संबंधित योजना के संदर्भ संग्रहीत करता है (plan_id ) और विकल्प (option_id ) यह जोड़ी, date_added . के साथ विशेषता, इस तालिका की UNIQUE कुंजी बनाती है। date_removed एट्रिब्यूट में केवल तभी मान होगा जब हमने किसी योजना से एक निश्चित विकल्प को हटाने का निर्णय लिया हो। ऐसा तब हो सकता है जब हम पुराने विकल्प को बदलने के लिए एक नया विकल्प बनाते हैं या हम अब किसी दिए गए विकल्प को नहीं रखने का निर्णय लेते हैं क्योंकि बहुत कम लोग इसका उपयोग करते हैं।

इस विषय क्षेत्र का अंतिम भाग विशेष या प्रचार प्रस्तावों से संबंधित है। सामान्य तौर पर, ऐसे ऑफ़र ग्राहकों को कम पैसे में अधिक सेवा देते हैं और एक निश्चित अवधि तक चलते हैं। उनका उद्देश्य मौजूदा ग्राहकों को नए ग्राहक प्राप्त करना या योजना उन्नयन (या सेवाओं की एक विस्तृत श्रृंखला) की बिक्री करना हो सकता है।

हमारे सभी प्रचार ऑफ़र offer टेबल। प्रत्येक ऑफ़र के लिए, हमें परिभाषित करना होगा:

offer_name - एक अनूठा नाम जिसे हमने इस ऑफ़र के लिए चुना है।
offer_start_date और offer_end_date - वह समयावधि जिसके दौरान यह ऑफ़र उपलब्ध है।
details - प्रस्ताव का विस्तृत पाठ्य विवरण।
छूट:हमें दो प्रकार की छूटों के लिए लचीलेपन की आवश्यकता है - एक निश्चित राशि-आधारित छूट (उदाहरण के लिए $50 की छूट) और एक प्रतिशत छूट (जैसे 25% की बचत)। यदि हम एक निश्चित छूट प्रदान करते हैं, तो हम उस मान को discount_amount . में डाल देंगे गुण; यदि हम प्रतिशत छूट प्रदान करते हैं, तो हम उस प्रतिशत को discount_percentage . में डाल देंगे विशेषता।
अवधि:हम यहां उसी तर्क का उपयोग करेंगे जिसका उपयोग हमने छूट के लिए किया है। कुछ मामलों में, ऑफ़र निर्धारित महीनों तक चलेगा (उदा. ग्राहकों के साइन अप करने के बाद 24 महीनों के लिए); इन मामलों में, हम duration_months . को परिभाषित करेंगे मूल्य। अन्य ऑफ़र एक निश्चित निश्चित तिथि (जैसे 31 दिसंबर, 2019 तक) तक मान्य होंगे; इनके लिए, हम तारीख को परिभाषित करेंगे और इसे duration_end_date . में स्टोर करेंगे विशेषता।

हम इस विषय क्षेत्र में शेष दो तालिकाओं का उपयोग यह परिभाषित करने के लिए करेंगे कि प्रत्येक ऑफ़र में क्या है और इसकी क्या पूर्वापेक्षाएँ हैं। इस उद्देश्य के लिए, हम दो तालिकाओं का उपयोग करेंगे:include और prerequisite . वे समान संरचना साझा करते हैं और उनमें offer_id . की समान UNIQUE जोड़ी होती है - plan_id . कुछ ऑफ़र में कोई पूर्वापेक्षाएँ नहीं हो सकती हैं, जबकि अन्य हो सकती हैं - उदा। यदि हम अधिक उपयोगकर्ताओं के साथ योजना में अपग्रेड करने के लिए छूट या किसी अन्य सॉफ़्टवेयर के उपयोगकर्ताओं के लिए सॉफ़्टवेयर सदस्यता की पेशकश कर रहे हैं।

ऑफ़र जटिल हो सकते हैं, इसलिए मैं कुछ उदाहरण प्रदान करूंगा।

यदि हम वर्तमान में योजना A का उपयोग करते हैं और हमारे पास योजना B में अपग्रेड करने का प्रस्ताव है, तो यह आसान है।
अगर हमारे पास दो ऑफ़र हैं, "प्लान ए अपग्रेड टू प्लान बी" और "प्लान बी अपग्रेड टू प्लान सी", तो हमें एक और ऑफर बनाना चाहिए:"प्लान ए अपग्रेड सीधे प्लान सी में"। यह उपयोगकर्ताओं को दो के बजाय एक चरण में अपनी योजनाओं को अपग्रेड करने की अनुमति देता है। इस तरह के अपग्रेड का एक उदाहरण एक सदस्यता को बदल रहा है जो वर्तमान में प्रति समूह पांच उपयोगकर्ताओं को एक की अनुमति देता है जो प्रति समूह 20 उपयोगकर्ताओं को बिना किसी मध्यवर्ती, दस-उपयोगकर्ता-प्रति-समूह योजना के रास्ते में रुकने की अनुमति देता है।
यदि कोई समूह उत्पाद ए का उपयोग करता है, तो हमारे पास प्रोमो मूल्य पर उत्पाद बी और सी की सदस्यता के लिए एक विशेष पेशकश हो सकती है। हमारे पास केवल उत्पाद B और केवल उत्पाद C की सदस्यता लेने के लिए दो अलग-अलग ऑफ़र हो सकते हैं।

सामान्य तौर पर, हमारे पास एक प्रस्ताव होना चाहिए जो वर्तमान योजना को बिना किसी चरण के वांछित योजना में बदल देगा और एक या अधिक नए उत्पादों की सदस्यता के लिए केवल एक प्रस्ताव होना चाहिए।

अनुभाग 3:सदस्यताएं, योजनाएं और भुगतान

अंतिम विषय क्षेत्र पहले बताए गए दो क्षेत्रों को जोड़ता है और इस मॉडल का सच्चा दिल है।

सभी सदस्यताएं subscription टेबल। हम प्रत्येक अलग योजना को एक अलग सदस्यता के रूप में मानेंगे, भले ही ये सदस्यताएँ/योजनाएँ एक ही ऑफ़र का परिणाम हों। इसका कारण यह है कि हम सब्सक्रिप्शन को अलग से प्रबंधित करने में सक्षम होंगे - उदा. अगर हम चाहें तो उन्हें अलग से रद्द कर दें। हमें यहां कई विवरण परिभाषित करने होंगे:

user_group_id - इस प्लान को सब्सक्राइब करने वाले ग्रुप की आईडी। यह महत्वपूर्ण है क्योंकि उपयोगकर्ताओं को व्यक्तिगत रूप से सदस्यता नहीं दी जाएगी; वे समूह के हिस्से के रूप में अप्रत्यक्ष रूप से सदस्यता लेते हैं।
trial_period_start_date और trial_period_end_date - इस सदस्यता के लिए परीक्षण अवधि (यदि कोई हो) की निचली और ऊपरी सीमाएं।
subscribe_after_trial - एक ध्वज यह दर्शाता है कि परीक्षण अवधि (यदि कोई हो) समाप्त होने के बाद सदस्यता स्वतः नवीनीकृत हो जाएगी।
current_plan_id - उस सदस्यता के लिए वर्तमान योजना। यदि सदस्यता अब सक्रिय नहीं है, तो इस विशेषता में अंतिम सक्रिय योजना का मूल्य होगा।
offer_id - इस सदस्यता से संबंधित ऑफ़र का संदर्भ। इस विशेषता में केवल तभी मान होगा जब यह सदस्यता किसी निश्चित ऑफ़र का परिणाम थी।
offer_start_date और offer_end_date - उस अवधि की निचली और ऊपरी सीमा, जिसके दौरान यह ऑफ़र सक्रिय था। इन विशेषताओं को तभी परिभाषित किया जाएगा जब यह सदस्यता किसी निश्चित ऑफ़र का परिणाम हो।
date_subscribed - जब इस समूह ने इस सदस्यता की सदस्यता ली।
valid_to - यह सदस्यता मान्य होने की अंतिम तिथि है। मासिक सदस्यता के मामले में, हम उम्मीद कर सकते हैं कि valid_to चालू माह के अंत तक सेट किया जाएगा। यदि कोई ग्राहक महीने के दौरान किसी भी समय सदस्यता समाप्त करता है, तब भी वे उस महीने के अंत तक अपने सॉफ़्टवेयर का उपयोग करने में सक्षम होंगे।
date_unsubscribed - वह तिथि जब उस समूह ने इस सदस्यता से सदस्यता समाप्त की। हम उम्मीद कर सकते हैं कि यह तिथि समूह व्यवस्थापक द्वारा मैन्युअल रूप से निर्धारित की जाएगी जब समूह अब सेवा का उपयोग नहीं करने का निर्णय लेता है। हालाँकि, इसे पूर्वनिर्धारित मानदंडों के अनुसार स्वचालित रूप से भी सेट किया जा सकता है - उदा। दो या दो से अधिक भुगतान न किए गए चालान होने पर समूह को उनकी सेवा से स्वतः सदस्यता समाप्त कर देता है।
insert_ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

सदस्यता योजनाएँ अक्सर समय के साथ बदलती रहती हैं। हमारी सभी योजनाओं का पूरा इतिहास बनाए रखने के लिए, हम सभी योजना परिवर्तनों को plan_history टेबल। यहां प्रत्येक रिकॉर्ड के लिए, हमें निम्न की आवश्यकता होगी:

subscription_id - संबंधित सदस्यता की आईडी।
plan_id - संबंधित योजना की आईडी।
date_start और date_end - वह समयावधि जब यह योजना सक्रिय थी।
insert_ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

हमारे मॉडल की अंतिम तालिका हमारे invoices . प्रत्येक चालान के लिए, हम निम्नलिखित विवरण रखेंगे:

customer_invoice_data - इस चालान के लिए बिल किए गए ग्राहक का विवरण। यह आपका डेटा होगाser_group.customer_invoice_data जिस समय इनवॉइस जनरेट किया गया था।
subscription_id - संबंधित सदस्यता की आईडी।
plan_history_id - इस चालान अवधि के दौरान सक्रिय योजना की आईडी।
invoice_period_start_date और invoice_period_end_date - इस इनवॉइस द्वारा कवर किया गया समय अंतराल (उदा. 1 जनवरी 2019 से 31 जनवरी 2019)।
invoice_description - चालान का एक संक्षिप्त पाठ विवरण।
invoice_amount - इस चालान के लिए देय भुगतान की राशि।
invoice_created_ts - जब यह इनवॉइस जनरेट किया गया और टेबल में डाला गया।
invoice_due_ts - जब यह चालान देय हो।
invoice_paid_ts - टाइमस्टैम्प जब इस चालान का भुगतान किया गया था।

हमें बताएं कि आप SaaS डेटा मॉडल के बारे में क्या सोचते हैं

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