כל מבנה הוא התחייבות

🌐 זמין גם ב-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)

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

פרק 3 בקורס Data Architect, חלק 1: להפוך לארכיטקט נתונים. הקודם: מידול נתונים למען המשמעות.

הנה שאלה שאני שואל בכל כיתה. אם מישהו אומר “אני עובד עם Salesforce”, מה שם ה-API של אובייקט המוצר?

זה Product2. זה מבחן הלקמוס הראשון שלי. איפשהו לאורך הדרך, Salesforce בנתה את אובייקט המוצר, הבינה שהוא לא עובד, ונאלצה להשאיר אותו מאחור. היא לא יכלה פשוט לקחת אותו, אז היא הוסיפה את Product2. אפילו Salesforce חיה עם המבנים הישנים שלה.

Salesforce גם השאירה לעצמה מקום לגדול. לאובייקטים הסטנדרטיים שלה אין קידומת או סיומת, ואנחנו, האנשים שמתאימים orgs, לעולם לא יכולים לתפוס את המרחב הזה. כך Salesforce יכולה להמשיך להוסיף אובייקטים ולעולם לא להתנגש בשום דבר שאנחנו בונים.

הנה הלקח: יצירת אובייקט לוקחת עשר דקות. לחיות איתו לוקח שנים. כל אובייקט וכל שדה שאתם מוסיפים הם התחייבות. הם תופסים אחסון. הם צוברים מגבלות. הם מקבלים מודל שיתוף, בין אם תכננתם אחד ובין אם לא. הם צריכים רישיון לכל אדם שנוגע בהם. ועכשיו גם בינה מלאכותית קוראת אותם, אז השם שאתם נותנים והתיאור שאתם כותבים קובעים מה סוכן מבין על הנתונים שלכם. להוסיף קל. לקחת בחזרה קשה.

הפרק הזה הופך את אבני הבניין של Salesforce להחלטות.

התמונה נוצרה באמצעות בינה מלאכותית.

המבנים במבט אחד

Salesforce נותנת לכם שישה מקומות להחזיק נתונים. אני שם אותם על שקף אחד, כי המשימה הראשונה היא לדעת שכולם קיימים:

מבנה	למה הוא משמש	המלכוד
אובייקטים סטנדרטיים	המודל של Salesforce עצמה: חשבון (Account), איש קשר (Contact), הזדמנות (Opportunity), פנייה (Case), נכס (Asset) וכל השאר	השתמשו בהם למה שהם נועדו, אחרת הם נלחמים בכם
אובייקטים מותאמים אישית	הנתונים העסקיים שלכם	קל ליצור, קשה להוציא משימוש
אובייקטים חיצוניים	נתונים שחיים במערכת אחרת ומוצגים ב-Salesforce	כל נגיעה היא קריאה יוצאת (callout)
Big objects	נפחים עצומים שחייבים לשמור אבל כמעט לא פותחים	אין ממשק או דיווח סטנדרטיים; שולפים דרך האינדקס
קבצים (Files)	מסמכים, תמונות ותוכן אחר	אחסון הקבצים מטפס מהר
קבצים מצורפים (Attachments)	הדרך הישנה לשמור קבצים	מורשת: השתמשו ב-Files

לבחור אחד זה רק חלק מהעניין. לפני המבנה באה השאלה איפה הנתונים צריכים לחיות בכלל: על הליבה, בהפניה למקום שבו הם כבר יושבים, או בארכיון.

המסלול דרך הפרק הזה

הפרק הזה גדול, אז הוא מגיע בעשרה חלקים. כל אחד עומד בפני עצמו. בפרק 2 החלטנו מה המודל צריך להיות; כאן אנחנו מחליטים איך הוא צריך לחיות ב-Salesforce.

1. פלטפורמת הנתונים של Salesforce: יותר ממסד נתונים. מה מייחד את Salesforce, ולמה לפלטפורמה יש צורה.
2. הביטו אל ספינת האם: מודלי הנתונים הסטנדרטיים. מודל המכירות ומודל השירות ש-Salesforce כבר בנתה, קבצים, אחסון, וחשבונות אישיים.
3. בנו בעצמכם: אובייקטים מותאמים אישית. מה מסך New Custom Object מחליט, השדות שלא יצרתם, ואיך לקרוא כל שם API: סטנדרטי, מותאם אישית או של חבילה מנוהלת.
4. איפה הנתונים האלה חיים? על הליבה, בהפניה, או בארכיון, הוחלט לפני שנוצר אובייקט כלשהו.
5. בחרו את האובייקט הנכון. מבחן ההתאמה הנקייה, המטען שאובייקטים סטנדרטיים מביאים איתם, חשבונות אישיים, והרישיונות שקובעים במה אנשים יכולים להשתמש.
6. גם שדות הם ארכיטקטורה. סוג שדה אחר סוג שדה, ההתנהגויות שמפתיעות אנשים, ולמה כל שדה מקבל תיאור.
7. לקשרים יש השלכות. lookup או master-detail, שלוש רמות לעומק ושני הורים לרוחב, אובייקט הצומת הלוגי ואובייקט הצומת של Salesforce (Salesforce Junction Object), והמגבלות שנושכות.
8. בעלות ומחזור חיים. מי הבעלים של רשומה, טבלת השיתוף שבה בעלות הופכת לגישה, ומה קורה לרשומה לאורך חייה.
9. שמירה על עקביות הנתונים. סולם העקביות: לכל שכבה יש מחיר, ולעולם לא “מתקנים” היסטוריה כדי לספק כלל חדש.
10. תכננו את המודל הפיזי ב-Salesforce. פרוסה של Steve Trucking, מהמודל הלוגי ל-Salesforce, נבנית צעד אחר צעד, עם הנימוקים.

כשתסיימו, בדקו את עצמכם עם מדריך הלימוד של הפרק: רשימת תיוג למבחן, ההרגלים שמעבר לו, מונחים שכדאי להכיר וכמה שאלות.

מה הארכיטקט מחליט כאן

• מה Salesforce כבר ממדלת, לפני שממציאים משהו: הביטו אל ספינת האם.
• איפה כל סוג נתונים חי, על הליבה, בהפניה או בארכיון, לפני שבוחרים מבנה.
• איזה מבנה מחזיק אותו, מתוך ידיעה על מה כל אחד מוותר.
• איך האובייקטים קשורים, מי הבעלים של הרשומות, ומה המשמעות של זה לגישה ולקנה מידה.
• באילו רישיונות המודל תלוי, נבדק לפני שמתכננים את האובייקטים, לא אחרי.
• איך הנתונים נשארים עקביים, ומה כל שכבת עקביות עולה.

מעבר למבחן: בנייה בעזרת בינה מלאכותית יכולה ליצור אובייקטים ושדות בתוך דקות. כשהוספה כמעט חינמית, “כל מבנה הוא התחייבות” חשוב יותר, לא פחות. כל יחידה מסתיימת במה שהבינה המלאכותית משנה בהחלטה הזו.

להרחבה

• 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 (באנגלית)

הבא: הבנת נתוני הארגון