हर संरचना एक प्रतिबद्धता है

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

Data Architect का अध्याय 3, भाग 1: डेटा आर्किटेक्ट बनना। पिछला: अर्थ के लिए डेटा मॉडलिंग।

यह सवाल मैं हर क्लास से पूछता हूँ। अगर कोई कहता है “मैं Salesforce के साथ काम करता हूँ,” तो प्रोडक्ट ऑब्जेक्ट का API नाम क्या है?

वह Product2 है। यह मेरी पहली कसौटी है। कहीं न कहीं Salesforce ने प्रोडक्ट ऑब्जेक्ट बनाया, समझ आया कि वह काम नहीं कर रहा, और उसे पीछे छोड़ना पड़ा। वे उसे यूँ ही हटा नहीं सकते थे, इसलिए उन्होंने Product2 जोड़ दिया। ख़ुद Salesforce भी अपनी पुरानी संरचनाओं के साथ जीता है।

Salesforce ने बढ़ने के लिए अपने लिए जगह भी छोड़ी। उसके स्टैंडर्ड ऑब्जेक्ट में कोई प्रीफ़िक्स या सफ़िक्स नहीं होता, और हम, org को कस्टमाइज़ करने वाले लोग, उस जगह पर कभी क़ब्ज़ा नहीं कर सकते। इसलिए Salesforce ऑब्जेक्ट जोड़ता रह सकता है और हमारी बनाई किसी चीज़ से कभी टकराता नहीं।

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

यह अध्याय Salesforce के बिल्डिंग ब्लॉक्स को फ़ैसलों में बदलता है।

यह तस्वीर AI से बनाई गई है।

एक नज़र में संरचनाएँ

Salesforce आपको डेटा रखने की छह जगहें देता है। मैं इन्हें एक ही स्लाइड पर रखता हूँ, क्योंकि पहला काम यह जानना है कि ये सब मौजूद हैं:

संरचना	किसलिए	पेच
स्टैंडर्ड ऑब्जेक्ट	Salesforce का अपना मॉडल: Account, Contact, Opportunity, Case, Asset और बाकी	इन्हें उसी काम के लिए इस्तेमाल करें जिसके लिए ये बने हैं, वरना ये आपसे लड़ेंगे
कस्टम ऑब्जेक्ट	आपका अपना बिज़नेस डेटा	बनाना आसान, हटाना मुश्किल
एक्सटर्नल ऑब्जेक्ट	ऐसा डेटा जो किसी दूसरे सिस्टम में रहता है, Salesforce में दिखाया जाता है	हर बार छूना एक callout है
Big objects	विशाल वॉल्यूम जिन्हें रखना ज़रूरी है पर कभी-कभार ही खोलना पड़ता है	कोई स्टैंडर्ड UI या रिपोर्टिंग नहीं; क्वेरी इंडेक्स के ज़रिए होती है
Files	डॉक्यूमेंट, फ़ोटो और दूसरा कंटेंट	फ़ाइल स्टोरेज तेज़ी से चढ़ता है
Attachments	फ़ाइलें स्टोर करने का पुराना तरीका	पुराना (legacy): Files इस्तेमाल करें

एक चुनना बस इसका एक हिस्सा है। संरचना से पहले यह सवाल आता है कि डेटा को रहना कहाँ चाहिए: core पर, जहाँ वह पहले से है वहीं रेफ़रेंस किया हुआ, या आर्काइव किया हुआ।

इस अध्याय का रास्ता

यह अध्याय बड़ा है, इसलिए यह दस हिस्सों में आता है। हर एक अपने आप में पूरा है। अध्याय 2 में हमने तय किया कि मॉडल कैसा होना चाहिए; यहाँ हम तय करते हैं कि वह Salesforce पर कैसे रहे।

1. Salesforce डेटा प्लेटफ़ॉर्म: डेटाबेस से कहीं बढ़कर। Salesforce को अलग क्या बनाता है, और प्लेटफ़ॉर्म का अपना आकार क्यों है।
2. मदरशिप की ओर देखें: स्टैंडर्ड डेटा मॉडल। Salesforce के पहले से बनाए Sales और Service मॉडल, फ़ाइलें, स्टोरेज, और Person Account।
3. अपना खुद का बनाएँ: कस्टम ऑब्जेक्ट। New Custom Object स्क्रीन क्या तय करती है, वे फ़ील्ड जो आपने नहीं बनाए, और कोई भी API नाम कैसे पढ़ें: स्टैंडर्ड, कस्टम या managed package।
4. यह डेटा कहाँ रहता है? core पर, रेफ़रेंस किया हुआ, या आर्काइव किया हुआ, कोई भी ऑब्जेक्ट बनाने से पहले तय किया गया।
5. सही ऑब्जेक्ट चुनें। साफ़ फ़िट की कसौटी, स्टैंडर्ड ऑब्जेक्ट अपने साथ जो बोझ लाते हैं, Person Account, और वे लाइसेंस जो तय करते हैं कि लोग क्या इस्तेमाल कर सकते हैं।
6. फ़ील्ड भी आर्किटेक्चर हैं। एक-एक फ़ील्ड टाइप, वे व्यवहार जो लोगों को चौंकाते हैं, और हर फ़ील्ड को विवरण क्यों मिलना चाहिए।
7. संबंधों के नतीजे होते हैं। Lookup या master-detail, तीन स्तर गहरे और दो पैरेंट चौड़े, तार्किक जंक्शन ऑब्जेक्ट और Salesforce Junction Object, और वे सीमाएँ जो चुभती हैं।
8. स्वामित्व और जीवनचक्र। रिकॉर्ड का मालिक कौन है, वह share टेबल जहाँ मालिकाना हक़ पहुँच (access) बन जाता है, और अपने जीवन में रिकॉर्ड के साथ क्या होता है।
9. डेटा को सुसंगत रखना। सुसंगतता की सीढ़ी: हर परत की एक क़ीमत है, और किसी नए नियम को संतुष्ट करने के लिए आप इतिहास को कभी “ठीक” नहीं करते।
10. Salesforce फ़िज़िकल मॉडल डिज़ाइन करें। Steve Trucking का एक हिस्सा, लॉजिकल मॉडल से Salesforce तक, कदम-दर-कदम बनाया हुआ, तर्क के साथ।

पूरा करने के बाद, अध्याय की अध्ययन गाइड से ख़ुद को परखें: परीक्षा के लिए एक चेकलिस्ट, उसके आगे की आदतें, जानने लायक शब्द, और कुछ सवाल।

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

• Salesforce पहले से क्या मॉडल करता है, कुछ भी नया बनाने से पहले: मदरशिप की ओर देखें।
• हर तरह का डेटा कहाँ रहता है, core पर, रेफ़रेंस किया हुआ या आर्काइव किया हुआ, संरचना चुनने से पहले।
• उसे कौन-सी संरचना रखती है, यह जानते हुए कि हर एक क्या छोड़ती है।
• ऑब्जेक्ट कैसे जुड़े हैं, रिकॉर्ड का मालिक कौन है, और पहुँच और स्केल के लिए इसका क्या मतलब है।
• मॉडल किन लाइसेंस पर निर्भर है, ऑब्जेक्ट डिज़ाइन करने से पहले जाँचा गया, बाद में नहीं।
• डेटा सुसंगत कैसे रहता है, और सुसंगतता की हर परत की क्या क़ीमत है।

परीक्षा से आगे: AI की मदद से बनाना मिनटों में ऑब्जेक्ट और फ़ील्ड बना सकता है। जब जोड़ना लगभग मुफ़्त हो, तो “हर संरचना एक प्रतिबद्धता है” कम नहीं, ज़्यादा मायने रखता है। हर मॉड्यूल इस बात पर ख़त्म होता है कि उस फ़ैसले के लिए AI क्या बदलता है।

और जानें

• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (अंग्रेज़ी में)
• Standard User Licenses (opens in a new tab), Salesforce Help (अंग्रेज़ी में)

अगला: एंटरप्राइज़ डेटा को समझना