डेटाबेस से कहीं बढ़कर

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 1 (कुल 10 में से) — अध्याय Salesforce डेटा आर्किटेक्चर, Data Architect कोर्स का अध्याय 3। हर मॉड्यूल अपने आप में पूरा है। अगला: मदरशिप की ओर देखें: स्टैंडर्ड डेटा मॉडल

यह मॉड्यूल किस सवाल का जवाब देता है: Salesforce किसी पारंपरिक डेटाबेस से अलग क्यों है?

अगर आप कुछ समय से Salesforce एडमिन हैं, तो आप ऑब्जेक्ट बनाना पहले से जानते हैं। Setup, Object Manager, New Custom Object। उसे एक नाम दें, कुछ फ़ील्ड जोड़ें, एक पेज लेआउट बनाएँ, और दस मिनट बाद यूज़र उस पर काम कर सकते हैं।

लेकिन जब आपने Save पर क्लिक किया, तब असल में हुआ क्या?

अगर आप डेटाबेस की पृष्ठभूमि से आते हैं, तो शायद आप सोचते हैं कि Salesforce ने जाकर एक नई टेबल बना दी। ऐसा नहीं हुआ। और यह समझना कि ऐसा क्यों नहीं हुआ, उन जगहों में से एक है जहाँ आप एडमिन या डेवलपर की तरह सोचने से आगे बढ़कर आर्किटेक्ट की तरह सोचना शुरू करते हैं।

Salesforce डेटा स्टोर करता है, बेशक; नीचे डेटाबेस हैं। लेकिन Salesforce ऊपर एक अच्छी स्क्रीन वाला डेटाबेस नहीं है। यह एक मेटाडेटा-आधारित (metadata-driven) एप्लिकेशन प्लेटफ़ॉर्म है, और यही फ़र्क इस कोर्स के लगभग हर निर्णय को आकार देता है।

प्लेटफ़ॉर्म का एक आकार होता है

अध्याय 2 में हमने Salesforce की चिंता किए बिना मॉडल बनाया था। ऐसा जानबूझकर किया था: हमने संज्ञाएँ (nouns) सुनीं, कॉन्सेप्चुअल मॉडल बनाया, एट्रिब्यूट, की और संबंध जोड़े, और उसके बाद ही पूछा कि Salesforce को इसे कैसे लागू करना चाहिए। अब हमें उस चीज़ को समझना है जिस पर हम इसे लागू कर रहे हैं।

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

मेटाडेटा ही ब्लूप्रिंट है

एक इमारत के बारे में सोचें। एक तो खुद इमारत है, और एक उसका ब्लूप्रिंट (नक्शा) है जो उसका वर्णन करता है: दीवारें कहाँ हैं, दरवाज़े कहाँ लगेंगे, कमरे आपस में कैसे जुड़ते हैं। Salesforce भी ऐसे ही काम करता है। ऑब्जेक्ट की परिभाषा मेटाडेटा है। फ़ील्ड की परिभाषा मेटाडेटा है। संबंध मेटाडेटा है। Setup में हम जो कुछ कॉन्फ़िगर करते हैं, उसका ज़्यादातर हिस्सा मेटाडेटा है, और प्लेटफ़ॉर्म रनटाइम पर उसे पढ़कर हमारे org को उसकी संरचना और व्यवहार देता है।

Salesforce अपने प्लेटफ़ॉर्म के केंद्र को multitenant और metadata-driven दोनों बताता है: जब हम कोई ऑब्जेक्ट या फ़ील्ड परिभाषित करते हैं, तो वह परिभाषा मेटाडेटा के रूप में स्टोर होती है, हमारे org के लिए किसी नई भौतिक टेबल या कॉलम के रूप में नहीं (Platform Multitenant Architecture (opens in a new tab))।

जब मैं यह पढ़ाता हूँ, तो मैं बोनट खोलकर अंदर दिखाता हूँ। हर बार जब आप कोई ऑब्जेक्ट जोड़ते हैं, Salesforce आपके लिए नया डेटाबेस नहीं बना रहा होता। वह अपनी ही टेबलों में एक रिकॉर्ड जोड़ रहा होता है: ऑब्जेक्ट की एक टेबल, फ़ील्ड की एक टेबल, डेटा की एक टेबल, और इंडेक्स व संबंधों के लिए पिवट टेबल, और ये सब एक org पहचानकर्ता (org identifier) से जुड़ी होती हैं जो आपके org के डेटा को बाकी सबके डेटा से अलग रखता है। इसलिए फ़ील्ड जोड़ना बस एक एंट्री जोड़ना है। यही वजह है कि आप चलते-चलते, लंच के समय, प्रोडक्शन में भी फ़ील्ड बना सकते हैं।

इससे एक और बात समझ आती है जिस पर लोग अटकते हैं। जब आप SELECT Id, Name, Special__c FROM Account लिखते हैं, तो यह एक ही टेबल जैसा दिखता है। अंदर आप स्टैंडर्ड ऑब्जेक्ट और उसके कस्टम फ़ील्ड को अलग-अलग संरचनाओं से पढ़ रहे होते हैं, यानी प्लेटफ़ॉर्म एक ऐसा join कर रहा होता है जो आपने कभी लिखा ही नहीं। इंडेक्स मौजूद हैं, लेकिन वे पारंपरिक डेटाबेस इंडेक्स की तरह काम नहीं करते। परीक्षा के लिए आपको अंदरूनी बारीकियाँ जानने की ज़रूरत नहीं है। लेकिन यह जानना ज़रूरी है कि Object Manager में जो दिखता है, वह भौतिक टेबलों की हूबहू तस्वीर नहीं है, और यह abstraction ही प्लेटफ़ॉर्म की ताकत भी है और उसके इस तरह व्यवहार करने की वजह भी।

Click to enlarge

मदरशिप की ओर देखें

क्लास में मैं लोगों से एक बात कहता हूँ: मदरशिप की ओर देखें। Salesforce पर कोई काम करने का कोई पेचीदा तरीका ईजाद करने से पहले, देखें कि खुद Salesforce उसे कैसे करता है।

Account को लें। उसे आपने नहीं बनाया; Salesforce ने बनाया। लेकिन आप उसमें फ़ील्ड जोड़ सकते हैं, उसके आसपास ऑटोमेशन बना सकते हैं, उसके लेआउट बदल सकते हैं, उसे API के ज़रिए बाहर दे सकते हैं और दूसरे ऑब्जेक्ट को उससे जोड़ सकते हैं। कस्टम ऑब्जेक्ट भी उसी मशीनरी पर चलते हैं, इसीलिए जब हम उन पर कुछ बनाते हैं तो स्टैंडर्ड और कस्टम ऑब्जेक्ट इतने मिलते-जुलते लगते हैं। Apex में तो उनकी base class भी एक ही है, sObject।

यही आदत इस अध्याय की नींव है, और अगले मॉड्यूल में हम ठीक से देखेंगे: उन स्टैंडर्ड डेटा मॉडल को जो Salesforce ने आपके लिए पहले से बना रखे हैं।

हम Salesforce के बगल में कुछ नहीं बना रहे। हम उसे आगे बढ़ा रहे हैं।

आपका API ऑब्जेक्ट के साथ ही आ गया

किसी पारंपरिक डेटाबेस में टेबल बनाइए, तो आपके पास एक टेबल होती है। अगर किसी दूसरे एप्लिकेशन को उसके साथ काम करना है, तो किसी को और काम करना पड़ेगा। Salesforce पर ऑब्जेक्ट बनाइए, और प्लेटफ़ॉर्म अपनी एप्लिकेशन और इंटीग्रेशन परतों के ज़रिए उसे पहले से समझता है: वह उसी मेटाडेटा से अपने REST और SOAP API देता है, इसलिए ऑब्जेक्ट बनते ही उसके रिकॉर्ड उन API से बनाए, पढ़े, अपडेट और डिलीट किए जा सकते हैं (Platform Multitenant Architecture (opens in a new tab))।

मैंने ऑब्जेक्ट बनाया, इसलिए मैंने कोई API डिज़ाइन नहीं किया। प्लेटफ़ॉर्म ऑब्जेक्ट को जानता है, उसके फ़ील्ड, उनके टाइप, उसके संबंध और उसकी सिक्योरिटी को जानता है। यह एक वजह है कि Salesforce डेवलपमेंट इतनी तेज़ी से चलता है। और इसी वजह से ऑब्जेक्ट बनाना दिखने से बड़ा निर्णय है: आप एक संरचना को पूरे एप्लिकेशन प्लेटफ़ॉर्म में प्लग कर रहे हैं। और यह बात उलटी दिशा में भी लागू होती है। SQL Server या Oracle से आए लोग कभी-कभी मुझसे पूछते हैं कि डेटा सीधे डेटाबेस में कैसे लोड करें। आप नहीं कर सकते। सब कुछ API के ज़रिए ही आता है।

अपार्टमेंट बिल्डिंग

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

आपका अपना अपार्टमेंट है। आपका फ़र्नीचर आपका है, और आपकी चाबी से मेरा दरवाज़ा नहीं खुलना चाहिए। लेकिन बिल्डिंग हम साझा करते हैं: बिजली, पानी, लिफ़्ट, लॉबी। आपका org आपको अपना माहौल लगता है, आपके डेटा, आपके ऑब्जेक्ट, आपके ऑटोमेशन के साथ। अंदर से, Salesforce हर org को एक tenant (किरायेदार) बताता है, जिसमें हर tenant का डेटा, मेटाडेटा और लॉजिक अलग रखा जाता है, जबकि इन्फ़्रास्ट्रक्चर और सेवाएँ साझा होती हैं (Platform Multitenant Architecture (opens in a new tab))। इसी तरह वह हर ग्राहक के लिए अलग स्टैक चलाए बिना हर ग्राहक को इतना कस्टमाइज़ होने वाला प्लेटफ़ॉर्म दे पाता है।

लेकिन बिल्डिंग साझा करने के नतीजे होते हैं। अगर कोई किरायेदार एक बहुत बड़ा एयर कंडीशनर ले आए और हेयर ड्रायर और ओवन एक साथ चला दे, तो फ़्यूज़ उड़ जाता है, और पूरे फ़्लोर की बत्ती गुल हो जाती है।

आप लिफ़्ट पर कब्ज़ा नहीं कर सकते

एक मिनट और बिल्डिंग में ही रहें। मान लीजिए एक निवासी घोषणा करता है, “मुझे सुबह आठ से दोपहर बारह बजे तक लिफ़्ट चाहिए। कोई और इसे इस्तेमाल नहीं कर सकता।” साझा बिल्डिंग में ऐसा नहीं चलता, और Salesforce पर भी नहीं चलता। किसी एक tenant को साझा संसाधन बिना सीमा के खर्च करने और बाकी सबके लिए प्लेटफ़ॉर्म धीमा करने की छूट नहीं दी जा सकती।

governor limits (प्लेटफ़ॉर्म की सीमाएँ) यहीं से आती हैं। अगर आपने Salesforce पर डेवलपमेंट किया है, तो शायद आप उनसे रटने वाले नंबरों की एक सूची के रूप में मिले होंगे। मैं नहीं चाहता कि आप उन्हें इस तरह देखें। Salesforce ट्रांज़ैक्शन और org के स्तर पर सीमाएँ लगाता है ताकि किसी एक tenant का काम साझा कंप्यूटिंग पर कब्ज़ा न कर ले (Architecture Basics (opens in a new tab))। यह आर्किटेक्चर है; हर अलग सीमा बस उसे लागू करने का तरीका है। कोर्स में आगे हम कुछ खास सीमाओं की परवाह करेंगे, क्योंकि वे डिज़ाइन बदल देती हैं। अभी के लिए, बिल्डिंग को याद रखें: अपने अपार्टमेंट को नए सिरे से सजाने की आपको बहुत आज़ादी है। लिफ़्ट पर कब्ज़ा करने की नहीं।

Salesforce ID भी abstraction का हिस्सा हैं

हर Salesforce रिकॉर्ड का एक ऐसा ID होता है जिसे प्लेटफ़ॉर्म समझता है, यानी रिकॉर्ड ID, और वह हर क्षमता में काम करता है: UI, API, रिपोर्ट, ऑटोमेशन।

अध्याय 2 में हमने कहा था कि एक अच्छी की यूनिक, न बदलने वाली, बिना अर्थ वाली और कभी PII नहीं होती है। Salesforce ID, Salesforce के लिए इस पर खरा उतरता है। लेकिन यह business key जैसी चीज़ नहीं है। हो सकता है आपकी कंपनी के पास अब भी ERP का ग्राहक नंबर, कर्मचारी नंबर या किसी पार्टनर का ऑर्डर नंबर हो, जिसका सभी सिस्टम में कोई अर्थ है। “Salesforce जानता है कि यह कौन-सा रिकॉर्ड है” को “एंटरप्राइज़ जानता है कि यह कौन-सी बिज़नेस चीज़ है” से न मिलाएँ। ये पहचानने की दो अलग समस्याएँ हैं, और दूसरी समस्या इंटीग्रेशन और मास्टर डेटा में फिर सामने आती है।

ऑब्जेक्ट सिर्फ़ स्टोरेज नहीं हैं

इस अध्याय के बाकी हिस्से से पहले मैं चाहता हूँ कि आप सोच में यह बदलाव करें। ऑब्जेक्ट सिर्फ़ डेटा रखने की जगह नहीं है। फ़ील्ड सिर्फ़ एक कॉलम नहीं है, और संबंध सिर्फ़ एक फ़ॉरेन की नहीं है। पढ़ाते समय मैं डेटाबेस की तुलनाएँ इस्तेमाल करता हूँ, क्योंकि वे उस चीज़ से जुड़ती हैं जो लोग पहले से जानते हैं। लेकिन अगर हम वहीं रुक गए, तो आर्किटेक्चर छूट जाएगा।

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

परीक्षा से आगे: AI क्या बदलता है। सालों तक अच्छे नाम और विवरण अगले एडमिन या डेवलपर को यह समझने में मदद करते रहे कि हमने क्या बनाया। अब मशीनें भी वह संदर्भ पढ़ती हैं। Flag2__c नाम के फ़ील्ड के साथ काम करने वाले AI सिस्टम की वही समस्या है जो एक नए डेवलपर की: इस चीज़ का मतलब क्या है? मेटाडेटा अब सजावट नहीं रहा; यह इस बात का हिस्सा है कि मशीनें एप्लिकेशन को कैसे समझती हैं।

आर्किटेक्ट यहाँ क्या तय करता है

• क्या मैं उस प्लेटफ़ॉर्म के लिए डिज़ाइन कर रहा हूँ जिस पर मैं सच में हूँ, या Salesforce को एक आम डेटाबेस की तरह देख रहा हूँ?
• मेरे डिज़ाइन के कौन-से हिस्से बिज़नेस की अवधारणाएँ हैं, और कौन-से Salesforce में लागू करने के चुनाव?
• जो संरचना मैं बनाने जा रहा हूँ, उसके साथ प्लेटफ़ॉर्म का कौन-सा व्यवहार आता है?
• कौन-सी सीमाएँ साझा आर्किटेक्चर की अभिव्यक्ति हैं, और उनमें से कौन-सी इस डिज़ाइन को आकार देंगी?
• अगर इस संरचना को बाद में बदलना मुश्किल होगा, तो क्या मैं इसे एक आर्किटेक्चरल निर्णय की तरह ले रहा हूँ?

अध्याय 2 में हमने कहा था: Setup से डिज़ाइन न करें। अब आप इसकी एक और वजह जानते हैं। New Custom Object पर क्लिक करने से आपको सिर्फ़ एक टेबल नहीं मिलती; यह आपके आर्किटेक्चर का एक और टुकड़ा एक मेटाडेटा-आधारित, multitenant प्लेटफ़ॉर्म से जोड़ देता है। लेकिन कौन-सा ऑब्जेक्ट बनाना है, यह तय करने से पहले एक और बुनियादी सवाल है: क्या यह डेटा यहाँ रहना भी चाहिए? वह आगे है।

और जानें

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया, 2026-10-12 को दोबारा जाँचा गया): ऑब्जेक्ट और फ़ील्ड की परिभाषाएँ मेटाडेटा के रूप में स्टोर होती हैं, नई टेबलों के रूप में नहीं; साझा टेबल (MT_Objects, MT_Fields, MT_Data, MT_Indexes) OrgID से जुड़ी होती हैं; वही मेटाडेटा REST और SOAP API देता है।
• Salesforce Architects, Architecture Basics (opens in a new tab) (अंग्रेज़ी में, 2026-10-02 को जाँचा गया, 2026-10-12 को दोबारा जाँचा गया): governor और execution limits, ताकि कोड और ट्रांज़ैक्शन “साझा कंप्यूटिंग संसाधनों पर एकाधिकार न करें” (“don’t monopolize shared compute resources”)।