यह डेटा कहाँ रहता है?

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 4 (कुल 10 में से) — अध्याय Salesforce डेटा आर्किटेक्चर, Data Architect कोर्स का अध्याय 3। हर मॉड्यूल अपने आप में पूरा है। पिछला: अपना खुद का बनाएँ: कस्टम ऑब्जेक्ट · अगला: सही ऑब्जेक्ट चुनें

यह मॉड्यूल किस सवाल का जवाब देता है: ऑब्जेक्ट बनाने से पहले, यह डेटा असल में कहाँ रहना चाहिए: Salesforce में core पर, वहीं से संदर्भित जहाँ वह पहले से है, या आर्काइव में?

एक सवाल पूछता हूँ। आपकी मेज़ पर एक नई requirement आती है। आप सबसे पहले क्या करते हैं?

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

तो पहला आर्किटेक्चर निर्णय यह नहीं है कि कौन-सा ऑब्जेक्ट। वह है यह डेटा कहाँ रहना चाहिए? इसे सही कर लें, तो ऑब्जेक्ट टाइप लगभग अपने-आप चुन लिया जाता है।

Core पर और core से बाहर

पहले, एक शब्द जो मैं बहुत इस्तेमाल करूँगा: core। Core वह Salesforce प्लेटफ़ॉर्म है जिस पर आपका org चलता है: मॉड्यूल 1 वाला मेटाडेटा-आधारित, multitenant प्लेटफ़ॉर्म, जहाँ मॉड्यूल 2 के Sales और Service ऑब्जेक्ट रहते हैं, और मॉड्यूल 3 में आप जो भी कस्टम ऑब्जेक्ट बनाते हैं। जब मैं कहता हूँ कि डेटा core पर है, तो मेरा मतलब है कि वह आपके org में, उसके ऑब्जेक्ट में स्टोर है।

सारा डेटा वहाँ नहीं रहता। Data 360 अपना डेटा अपने स्टोर में रखता है, आपके org के ऑब्जेक्ट से बाहर (यह near-core (core के पास) है: core पर मैनेज होता है, उसका डेटा core से बाहर होस्ट होता है; और जानकारी अध्याय 4 में)। और फिर वह सब कुछ है जो आपकी कंपनी चलाती है और जो Salesforce है ही नहीं: ERP, वेयरहाउस, ऑर्डर सिस्टम, पार्टनर का प्लेटफ़ॉर्म। वह सब core से बाहर है। Salesforce उस तक पहुँच सकता है, उसे दिखा सकता है और इस्तेमाल कर सकता है, लेकिन आपका org उसे स्टोर नहीं करता।

Core पर दो तरह के ऑब्जेक्ट हैं जो असल में आपके रिकॉर्ड रखते हैं: sObjects, स्टैंडर्ड और कस्टम (__c), और big objects (__b)। Core से बाहर, आप एक्सटर्नल ऑब्जेक्ट (__x) और दूसरे इंटीग्रेशन टूल के ज़रिए डेटा तक पहुँचते हैं। मॉड्यूल 3 के वे suffix याद रखें; वे सिर्फ़ नाम से बता देते हैं कि डेटा का कोई टुकड़ा कहाँ रहता है।

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

1. Core पर: यह आपकी मेज़ पर रहता है

डेटा हर दिन Salesforce में बनता है, बदलता है और इस्तेमाल होता है: accounts, cases, opportunities, work orders। इसे sObjects में रखना ऐसा है जैसे इसे अपने दफ़्तर के सामने वाले हिस्से में रखना। स्टैंडर्ड और कस्टम ऑब्जेक्ट इसी के लिए हैं, और आपको सब कुछ मिलता है: पेज लेआउट, शेयरिंग, ऑटोमेशन, रिपोर्टिंग, सर्च, और अब डेटा मॉडल पर बने AI फ़ीचर।

लेकिन आपकी मेज़ मुफ़्त नहीं है। Core पर रखा डेटा स्टोरेज लेता है, उसी तरह गिनकर जैसे Salesforce गिनता है, रिकॉर्ड-दर-रिकॉर्ड, कॉलम-दर-कॉलम नहीं, और दस्तावेज़ अलग से file storage में गिने जाते हैं। ये दोनों हमने मॉड्यूल 2 में देखे थे। फ़ोटो और स्कैन की बड़ी मात्रा की जगह अक्सर core से बाहर होती है, और Salesforce सिर्फ़ एक लिंक रखता है।

2. संदर्भित: यह किसी और की फ़ाइल कैबिनेट में रहता है

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

यह है Salesforce Connect के ज़रिए एक्सटर्नल ऑब्जेक्ट। मैं कहना पसंद करता हूँ कि यह बत्तख जैसा दिखता है और बत्तख जैसा चलता है, लेकिन यह बत्तख नहीं है। यह sObject की तरह दिखता है: आप इसे पेज लेआउट और related lists पर रख सकते हैं, और external और indirect lookups से अपने रिकॉर्ड से जोड़ सकते हैं। लेकिन डेटा core पर स्टोर नहीं होता। हर बार जब आप इसे छूते हैं, यह एक callout करता है। कोई रिकॉर्ड खोलें, कोई related list लोड करें, कोई रिपोर्ट चलाएँ, और Salesforce जाकर दूसरे सिस्टम से पूछता है। इसका मतलब है देरी (latency), और आपका पेज उतना ही उपलब्ध है जितना उसके पीछे का सिस्टम।

लोग लाइसेंस की कीमत पर आपत्ति करते हैं, तो वैसे हिसाब लगाइए जैसे मैं क्लास में लगाता हूँ। Connect का लाइसेंस हर endpoint के हिसाब से होता है, और एक endpoint कई ऑब्जेक्ट ला सकता है। अब पूछिए कि उसका विकल्प बनाने और चलाए रखने में कितना खर्च होगा: एक कस्टम कंपोनेंट, उसके पीछे का callout कोड, और टूटने पर एक डेवलपर जो तैयार बैठा हो। अक्सर लाइसेंस सस्ता पड़ता है, और आपके एडमिन एक भी लाइन कोड लिखे बिना इसे कॉन्फ़िगर कर सकते हैं। यह कहाँ कमज़ोर पड़ता है: ऐसा डेटा जिसे आपके यूज़र दिन भर एडिट करते हैं, या जिस पर भारी रिपोर्टिंग होती है।

दस्तावेज़ भी संदर्भित किए जा सकते हैं। अगर कोई कॉन्ट्रैक्ट पहले से SharePoint Online, OneDrive, Google Drive या Box में है, तो Files Connect यूज़र को उसे Salesforce में कॉपी किए बिना Salesforce से ही खोलने देता है।

डेटा को संदर्भित करने का Salesforce Connect अकेला तरीका नहीं है। कभी-कभी यह कस्टम लॉजिक होता है: ऐसा कोड जो दूसरे सिस्टम को रियल टाइम में कॉल करता है और उसका डेटा पेज पर दिखाता है, बिना कोई कॉपी रखे। इससे आपको पूरा नियंत्रण मिलता है, और callout, errors और रखरखाव की पूरी ज़िम्मेदारी भी। और Data 360 भी बिना कॉपी किए federate कर सकता है। उस चुनाव का अपना अध्याय है (वर्चुअलाइज़ेशन, फ़ेडरेशन और Zero-Copy)। यहाँ बात खुद निर्णय की है: संदर्भ दें, कॉपी न करें।

3. आर्काइव: यह पीछे के शेड में जाता है

इतिहास, ऑडिट ट्रेल, पुराने ट्रांज़ैक्शन। आपको इन्हें रखना पड़ता है, कभी-कभी सालों तक, लेकिन लगभग कोई इन्हें खोलता नहीं। और यही वह काम है जिसे टीमें टालती रहती हैं। जब कोई क्लास मुझे बताती है कि उनके पास 50 मिलियन रिकॉर्ड वाला एक ऑब्जेक्ट है और पूछती है कि वे आर्काइव क्यों करें, तो मैं उनसे उल्टा पूछता हूँ: अगर आप आज आर्काइव नहीं कर रहे, तो क्या आप कभी करेंगे? आज 50 मिलियन पर हैं, तो आप 100, 150, 200 मिलियन की ओर बढ़ रहे हैं।

दो शेड हैं। एक है core पर: big objects। इन्हें गैराज में डेटा रखने जैसा समझें। आप बहुत बड़ी संख्या में रिकॉर्ड रख सकते हैं, लेकिन उन्हें पेज लेआउट पर नहीं रख सकते, कोई स्टैंडर्ड UI या रिपोर्टिंग नहीं है, और आप big object के इंडेक्स से ही query करते हैं, सटीक मिलान या रेंज से (Big Objects Best Practices (opens in a new tab))। सिक्योरिटी सिर्फ़ ऑब्जेक्ट और फ़ील्ड की permissions से होती है, रिकॉर्ड शेयरिंग नहीं होती, और उन पर ऑटोमेशन नहीं चलता। मैंने Salesforce Connect दर्जनों बार इस्तेमाल किया है और big objects सिर्फ़ एक-दो बार। वे काम करते हैं, लेकिन असुविधाजनक हैं, और डेटा तक पहुँचने के लिए मैंने अपने हिस्से के जुगाड़ (workarounds) लिखे हैं। इसलिए मेरी सलाह: सुझाने से पहले इसका प्रोटोटाइप बनाएँ, और इसे चुनने से पहले योजना बनाएँ कि लोग डेटा को कैसे ढूँढेंगे।

दूसरा शेड है core से बाहर: कहीं और एक वेयरहाउस या डेटाबेस (स्केल के लिए डिज़ाइन)। अक्सर वह बेहतर शेड होता है, और उसका नज़रों से ओझल होना ज़रूरी नहीं। Core से बाहर आर्काइव किया गया डेटा Tableau जैसे टूल के ज़रिए अब भी रिपोर्ट में दिख सकता है, और जब किसी को पीछे देखना हो, तो Salesforce Connect या उसे वर्चुअलाइज़ करने के किसी और तरीके से Salesforce से अब भी उस तक पहुँचा जा सकता है।

एक प्रोजेक्ट के बारे में बताता हूँ जहाँ हमने इसे शुरू से सही किया। एक रिटेल क्लाइंट के 1,200 से ज़्यादा लोकेशन थे। उन्होंने मुझसे कहा, “हम एक स्टोर पर दिन में सिर्फ़ सौ अपॉइंटमेंट करते हैं। कोई बड़ी बात नहीं।” फिर मैंने हिसाब लगाया: दिन में सौ, हफ़्ते में छह दिन (साल में लगभग 305 दिन), 1,200 लोकेशन पर, यानी साल में 36 मिलियन से ज़्यादा अपॉइंटमेंट। फिर उन्होंने बताया कि हर विज़िट में दो अपॉइंटमेंट बनते थे, एक सामने के काउंटर पर और एक दुकान के पीछे वाले हिस्से के लिए: साल में 73 मिलियन से ज़्यादा रिकॉर्ड। फिर उन्हें पाँच साल का इतिहास चाहिए था: किसी भी बढ़ोतरी से पहले ही 360 मिलियन से ज़्यादा रिकॉर्ड। हम अभी लाइव भी नहीं हुए थे, और मुझे ट्रेन सीधे large-data-volume स्टेशन की ओर जाती दिख रही थी। इसलिए एक भी अपॉइंटमेंट इकट्ठा करने से पहले आर्काइव बना दिया गया: पुराने अपॉइंटमेंट big objects में चले गए, और सर्च स्क्रीन मौजूदा अपॉइंटमेंट दिखाती थी, ठीक नीचे आर्काइव वाले। सालों बाद भी, वह आराम से चल रहा है।

Click to enlarge

इसे काम में लाना: Steve Trucking

Steve Trucking हमारा चलता हुआ उदाहरण है: एक पारिवारिक last-mile डिलीवरी कंपनी जो बड़े रिटेलरों के डिस्ट्रिब्यूशन सेंटर (DC) से appliances और इलेक्ट्रॉनिक्स उठाती है, फिर उन्हें ग्राहकों के घर पहुँचाकर इंस्टॉल करती है। इसके डेटा के चार प्रकार, तीन जवाब:

डेटा	यह कहाँ रहता है	क्यों
आज की डिलीवरी, क्रू और अपॉइंटमेंट	Core पर	डिस्पैचर और क्रू दिन भर इसी में काम करते हैं
रिटेलर के ऑर्डर का ब्योरा	संदर्भित (या core पर एक पतली कॉपी)	रिटेलर का सिस्टम सच का स्रोत है
तीन साल पहले का डिलीवरी इतिहास	आर्काइव	क्लेम और ट्रेंड के लिए रखा जाता है; लगभग कोई इसे नहीं खोलता
डिलीवरी की फ़ोटो	Core से बाहर, लिंक के साथ	दिन में हज़ारों; Salesforce के बाहर स्टोर, डिलीवरी पर एक लिंक के साथ

यही बात एक डेटा मॉडल के रूप में। डिलीवरी (Delivery) core पर है, जहाँ लोग दिन भर उसमें काम करते हैं। तीन साल बाद, वह Delivery History में चली जाती है, जो एक big object है: अब भी core पर, लेकिन बाहर शेड में। पार्टनर का ऑर्डर एक एक्सटर्नल ऑब्जेक्ट के रूप में दिखता है, __x: Salesforce डिलीवरी को उससे जोड़ता है, लेकिन डेटा रिटेलर के सिस्टम में रहता है। और फ़ोटो पूरी तरह core से बाहर रहती हैं, डिलीवरी से एक लिंक के साथ। एक मॉडल, तीन घर।

Click to enlarge

हर असली org में ये तीनों होते हैं। मुसीबत में वे पड़ते हैं जो सब कुछ core पर डाल देते हैं, क्योंकि ऑब्जेक्ट बनाना ही डिफ़ॉल्ट बटन था।

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

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

परीक्षा से आगे: AI “core पर” का दाँव बढ़ा देता है। AI फ़ीचर और एजेंट उस डेटा पर सबसे अच्छा काम करते हैं जिसे प्लेटफ़ॉर्म समझता है: स्टैंडर्ड और कस्टम ऑब्जेक्ट में रखा डेटा, अच्छे नाम और अच्छे विवरण के साथ। यह ज़्यादा डेटा core पर रखने की ओर खींचता है। गलत डेटा के लिए इस खिंचाव का विरोध करें। ERP डेटा की पुरानी कॉपी पर आधारित (grounded) एजेंट पूरे भरोसे के साथ गलत जवाब देता है। अक्सर बेहतर कदम है लाइव स्रोत को संदर्भित करना, या core पर एक छोटा, अच्छी तरह वर्णित हिस्सा रखना। AI डेटा कहाँ पढ़ता है, यह अब इस निर्णय का हिस्सा है कि डेटा कहाँ रहे।

और जानें

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (अंग्रेज़ी में, 2026-09-25 को जाँचा गया)
• Files Connect FAQ (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-09-25 को जाँचा गया)
• इस कोर्स में: वर्चुअलाइज़ेशन, फ़ेडरेशन और Zero-Copy और स्केल के लिए डिज़ाइन