איפה הנתונים האלה חיים?

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

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

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

יחידה 4 מתוך 10 בפרק ארכיטקטורת הנתונים של Salesforce, הפרק השלישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: בנו בעצמכם: אובייקטים מותאמים אישית · הבא: בחרו את האובייקט הנכון

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

תנו לי לשאול אתכם שאלה. דרישה חדשה נוחתת לכם על השולחן. מה הדבר הראשון שאתם עושים?

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

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

על הליבה ומחוץ לליבה

קודם, מילה שאשתמש בה הרבה: core (ליבה). הליבה היא פלטפורמת Salesforce שה-org שלכם רץ עליה: הפלטפורמה מונעת המטא-דאטה עם ריבוי הדיירים מיחידה 1, שבה חיים אובייקטי המכירות והשירות מיחידה 2, וכל אובייקט מותאם אישית שאתם בונים ביחידה 3. כשאני אומר שנתונים נמצאים על הליבה (on core), אני מתכוון שהם מאוחסנים ב-org שלכם, באובייקטים שלו.

לא כל הנתונים חיים שם. Data 360 שומר את הנתונים שלו במאגר משלו, מחוץ לאובייקטים של ה-org שלכם (הוא קרוב לליבה (near-core): מנוהל על הליבה, והנתונים שלו מתארחים מחוץ לליבה; עוד על זה בפרק 4). ויש גם את כל מה שהחברה שלכם מריצה ושאינו Salesforce בכלל: ה-ERP, המחסן, מערכת ההזמנות, הפלטפורמה של השותף. כל זה מחוץ לליבה (off core). Salesforce יכולה להגיע לזה, להציג את זה ולהשתמש בזה, אבל ה-org שלכם לא מאחסן את זה.

על הליבה, יש שני סוגי אובייקטים שבאמת מחזיקים את הרשומות שלכם: sObjects, סטנדרטיים ומותאמים אישית (__c), ו-big objects (__b). מחוץ לליבה, מגיעים לנתונים דרך אובייקטים חיצוניים (__x) ושאר כלי האינטגרציה. זכרו את הסיומות מיחידה 3; הן אומרות לכם איפה פיסת נתונים חיה רק לפי השם שלה.

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

1. על הליבה: זה חי על השולחן שלכם

הנתונים נוצרים, משתנים ונמצאים בשימוש ב-Salesforce כל יום: חשבונות, פניות, הזדמנויות, הזמנות עבודה. לשמור אותם ב-sObjects זה כמו לשמור אותם בחזית המשרד. בשביל זה קיימים אובייקטים סטנדרטיים ומותאמים אישית, ואתם מקבלים הכול: page layouts, שיתוף, אוטומציה, דוחות, חיפוש, ועכשיו גם את יכולות ה-AI שבנויות על מודל הנתונים.

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

2. בהפניה: זה חי בארון התיוק של מישהו אחר

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

אלה אובייקטים חיצוניים, דרך Salesforce Connect. אני אוהב לומר שזה נראה כמו ברווז והולך כמו ברווז, אבל זה לא ברווז. זה מופיע כמו sObject: אפשר לשים את זה ב-page layouts וברשימות קשורות, ולקשר את זה לרשומות שלכם עם external lookups ו-indirect lookups. אבל הנתונים לא מאוחסנים על הליבה. בכל פעם שנוגעים בזה, יוצאת קריאה החוצה (callout). פותחים רשומה, טוענים רשימה קשורה, מריצים דוח, ו-Salesforce הולכת ושואלת את המערכת האחרת. זה אומר השהיה, והעמוד שלכם זמין רק כמו המערכת שמאחוריו.

אנשים מתנגדים בגלל עלות הרישיון, אז תעשו את החשבון כמו שאני עושה בכיתה. Connect מתומחר לפי endpoint, ו-endpoint אחד יכול להביא הרבה אובייקטים. עכשיו תשאלו כמה עולה לבנות ולתחזק את החלופה: רכיב מותאם אישית, קוד ה-callout שמאחוריו, ומפתח בכוננות כשזה נשבר. לעיתים קרובות הרישיון זול יותר, והאדמינים שלכם יכולים להגדיר אותו בלי לכתוב שורת קוד אחת. איפה זה נופל: נתונים שהמשתמשים שלכם עורכים כל היום, או מפיקים עליהם הרבה דוחות.

גם מסמכים יכולים להיות בהפניה. אם חוזה כבר נמצא ב-SharePoint Online, OneDrive, Google Drive או Box, Files Connect מאפשר למשתמשים להגיע אליו מ-Salesforce בלי להעתיק אותו פנימה.

Salesforce Connect היא לא הדרך היחידה להפנות לנתונים. לפעמים זו לוגיקה מותאמת אישית: קוד שקורא למערכת האחרת בזמן אמת ומציג את הנתונים שלה בעמוד, בלי לשמור עותק. זה נותן לכם שליטה מלאה, ואחריות מלאה על ה-callout, על השגיאות ועל התחזוקה. וגם Data 360 יכול לבצע פדרציה בלי להעתיק. לבחירה הזו יש פרק משלה (וירטואליזציה, פדרציה ו-Zero-Copy). כאן, הנקודה היא ההחלטה עצמה: להפנות, לא להעתיק.

3. בארכיון: זה הולך למחסן שבחצר

היסטוריה, תיעוד ביקורת, טרנזקציות ישנות. אתם חייבים לשמור את זה, לפעמים שנים, אבל כמעט אף אחד לא פותח את זה. וזה הדבר שצוותים דוחים. כשכיתה מספרת לי שיש לה אובייקט עם 50 מיליון רשומות ושואלת למה שתעביר לארכיון, אני שואל בחזרה: אם אתם לא מעבירים לארכיון היום, האם אי פעם תעבירו? עם 50 מיליון היום, אתם בדרך ל-100, ל-150, ל-200 מיליון.

יש שני מחסנים. אחד על הליבה: big objects. תחשבו עליהם כעל אחסון נתונים במוסך. אפשר לאחסן מספר עצום של רשומות, אבל אי אפשר לשים אותן ב-page layout, אין ממשק משתמש או דוחות סטנדרטיים, ושואלים דרך האינדקס של ה-big object, בהתאמה מדויקת או בטווח (Big Objects Best Practices (opens in a new tab)). האבטחה היא הרשאות אובייקט ושדה בלבד, בלי שיתוף רשומות, ואוטומציה לא רצה עליהם. השתמשתי ב-Salesforce Connect עשרות פעמים וב-big objects רק פעם או פעמיים. הם עובדים, אבל הם מסורבלים, וכתבתי לא מעט מעקפים כדי להגיע לנתונים. אז העצה שלי: בנו אב-טיפוס לפני שאתם מציעים את זה, ותכננו איך אנשים ימצאו את הנתונים לפני שאתם בוחרים בזה.

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

תנו לי לספר לכם על פרויקט שבו עשינו את זה נכון מההתחלה. ללקוח קמעונאי היו יותר מ-1,200 סניפים. הם אמרו לי: “אנחנו עושים רק מאה פגישות ביום בחנות. לא עניין גדול.” ואז עשיתי את החשבון: מאה ביום, שישה ימים בשבוע (בערך 305 ימים בשנה), ב-1,200 סניפים, זה יותר מ-36 מיליון פגישות בשנה. ואז הם הזכירו שכל ביקור יוצר שתי פגישות, אחת בדלפק הקדמי ואחת לחלק האחורי של החנות: יותר מ-73 מיליון רשומות בשנה. ואז הם רצו חמש שנים של היסטוריה: יותר מ-360 מיליון רשומות, לפני כל צמיחה. עוד לא עלינו לאוויר, וכבר יכולתי לראות את הרכבת דוהרת ישר לתחנת נפחי הנתונים הגדולים. אז הארכיון נבנה לפני שאספנו פגישה אחת: פגישות ישנות עברו ל-big objects, ומסך החיפוש הציג את הפגישות הנוכחיות ואת אלה שבארכיון ממש מתחתן. שנים אחר כך, זה עדיין רץ מצוין.

Click to enlarge

ליישם את זה: Steve Trucking

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

נתונים	איפה הם חיים	למה
המשלוחים, הצוותים והפגישות של היום	על הליבה	הסדרנים והצוותים עובדים בהם כל היום
פרטי ההזמנה של הקמעונאי	בהפניה (או עותק דק על הליבה)	המערכת של הקמעונאי היא מקור האמת
היסטוריית משלוחים משלוש שנים אחורה	בארכיון	נשמרת לתביעות ולמגמות; כמעט אף אחד לא פותח אותה
תמונות משלוחים	מחוץ לליבה, עם קישור	אלפים ביום; מאוחסנות מחוץ ל-Salesforce עם קישור על המשלוח

הנה אותו דבר כמודל נתונים. המשלוח (Delivery) יושב על הליבה, שם אנשים עובדים בו כל היום. אחרי שלוש שנים, הוא עובר ל-Delivery History, big object: עדיין על הליבה, אבל בחוץ במחסן. ההזמנה של השותף מופיעה כאובייקט חיצוני, __x: Salesforce מקשרת אליה את המשלוח, אבל הנתונים נשארים במערכת של הקמעונאי. והתמונות חיות מחוץ לליבה לגמרי, עם קישור מהמשלוח. מודל אחד, שלושה בתים.

Click to enlarge

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

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

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

מעבר למבחן: ה-AI מעלה את ההימור על “על הליבה”. יכולות AI וסוכנים עובדים הכי טוב על נתונים שהפלטפורמה מבינה: נתונים באובייקטים סטנדרטיים ומותאמים אישית, עם שמות טובים ותיאורים טובים. זה מושך לכיוון של לשים יותר על הליבה. תתנגדו לזה כשמדובר בנתונים הלא נכונים. סוכן שמעוגן בעותק מיושן של נתוני ה-ERP נותן תשובות בטוחות בעצמן ושגויות. לעיתים קרובות המהלך הטוב יותר הוא להפנות למקור החי, או לשמור על הליבה פרוסה קטנה עם תיאור טוב. המקום שבו ה-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 ו-תכנון לקנה מידה