יותר ממסד נתונים

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

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

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

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

השאלה שהיחידה הזו עונה עליה: מה מבדיל את Salesforce ממסד נתונים מסורתי?

אם אתם אדמינים של Salesforce כבר זמן מה, אתם יודעים איך יוצרים אובייקט. Setup, Object Manager, New Custom Object. נותנים לו שם, מוסיפים כמה שדות, בונים page layout, ועשר דקות אחר כך המשתמשים כבר עובדים איתו.

אבל מה בעצם קרה כשלחצתם על Save?

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

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

לפלטפורמה יש צורה

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

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

המטא-דאטה היא תוכנית הבנייה

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

Salesforce מתארת את לב הפלטפורמה גם כ-multitenant (ריבוי דיירים) וגם כ-metadata-driven (מונעת מטא-דאטה): כשאנחנו מגדירים אובייקט או שדה, ההגדרה נשמרת כמטא-דאטה, ולא כטבלה או עמודה פיזית חדשה עבור ה-org שלנו (Platform Multitenant Architecture (opens in a new tab)).

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

זה גם מסביר משהו שאנשים נתקלים בו. כשאתם כותבים SELECT Id, Name, Special__c FROM Account, זה נראה כמו טבלה אחת. מתחת לפני השטח, אתם קוראים את האובייקט הסטנדרטי ואת השדה המותאם אישית שלו ממבנים שונים, כך שהפלטפורמה עושה join שמעולם לא כתבתם. יש אינדקסים, אבל הם לא עובדים כמו אינדקס של מסד נתונים מסורתי. לא צריך להכיר את הפרטים הפנימיים בשביל המבחן. כן צריך לדעת ש-מה שאתם רואים ב-Object Manager הוא לא תמונה אחד-לאחד של טבלאות פיזיות, ושההפשטה היא גם הכוח של הפלטפורמה וגם הסיבה שהיא מתנהגת כפי שהיא מתנהגת.

Click to enlarge

הביטו אל ספינת האם

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

קחו את חשבון (Account). לא אתם יצרתם אותו; Salesforce יצרה. אבל אפשר להוסיף לו שדות, לבנות סביבו אוטומציה, לשנות את ה-layouts שלו, לחשוף אותו דרך ממשקי ה-API ולקשר אליו אובייקטים אחרים. אובייקטים מותאמים אישית רצים על אותה מכונה, ולכן אובייקטים סטנדרטיים ומותאמים אישית מרגישים כל כך דומים כשאנחנו בונים עליהם. ב-Apex יש להם אפילו מחלקת בסיס משותפת, ה-sObject.

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

אנחנו לא בונים לצד Salesforce. אנחנו מרחיבים אותה.

ה-API שלכם הגיע עם האובייקט

צרו טבלה במסד נתונים מסורתי, ויש לכם טבלה. אם אפליקציה אחרת צריכה לעבוד איתה, למישהו מחכה עוד עבודה. צרו אובייקט ב-Salesforce, והפלטפורמה כבר מכירה אותו דרך שכבות האפליקציה והאינטגרציה שלה: היא משתמשת באותה מטא-דאטה כדי לספק את ממשקי ה-REST וה-SOAP שלה, כך שאפשר ליצור, לקרוא, לעדכן ולמחוק את הרשומות של האובייקט דרכם ברגע שהאובייקט קיים (Platform Multitenant Architecture (opens in a new tab)).

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

בניין הדירות

ועכשיו המילה ששומעים כל הזמן: multitenancy (ריבוי דיירים). אני חושב עליה כעל בניין דירות.

יש לכם את הדירה שלכם. הרהיטים שלכם הם שלכם, והמפתח שלכם לא אמור לפתוח את הדלת שלי. אבל אנחנו חולקים את הבניין: החשמל, המים, המעליות, הלובי. ה-org שלכם מרגיש כמו הסביבה הפרטית שלכם, עם הנתונים שלכם, האובייקטים שלכם, האוטומציה שלכם. מתחת לפני השטח, Salesforce מתארת כל org כדייר (tenant), ומבודדת את הנתונים, המטא-דאטה והלוגיקה של כל דייר, בזמן שהתשתית והשירותים משותפים (Platform Multitenant Architecture (opens in a new tab)). כך היא יכולה לתת לכל לקוח פלטפורמה כל כך גמישה בלי להריץ stack נפרד לכל אחד.

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

אי אפשר להשתלט על המעלית

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

מכאן מגיעים ה-governor limits (מגבלות הפלטפורמה). אם פיתחתם ב-Salesforce, בטח פגשתם אותם כרשימת מספרים לשנן. אני לא רוצה שתחשבו עליהם ככה. Salesforce מפעילה מגבלות ברמת הטרנזקציה וברמת ה-org כדי שעומס העבודה של דייר אחד לא ישתלט על משאבי המחשוב המשותפים (Architecture Basics (opens in a new tab)). זו הארכיטקטורה; כל מגבלה בודדת היא רק המימוש שלה. בהמשך הקורס יהיה לנו אכפת ממגבלות מסוימות כי הן משנות תכנון. בינתיים, זכרו את הבניין: יש לכם חופש עצום לשפץ את הדירה. אתם לא מקבלים להשתלט על המעלית.

מזהי Salesforce הם חלק מההפשטה

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

בפרק 2 אמרנו שמפתח טוב הוא ייחודי, לא משתנה, חסר משמעות ואף פעם לא PII. מזהה Salesforce עומד בזה עבור Salesforce. אבל הוא לא אותו דבר כמו מפתח עסקי. בחברה שלכם עדיין יכולים להיות מספר לקוח ב-ERP, מספר עובד או מספר הזמנה של שותף שיש להם משמעות בין מערכות. אל תבלבלו בין “Salesforce יודעת איזו רשומה זו” לבין “הארגון יודע איזה דבר עסקי זה”. אלה שתי בעיות זיהוי שונות, והשנייה חוזרת באינטגרציה ובנתוני אב.

אובייקטים הם יותר מאחסון

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

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

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

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

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

בפרק 2 אמרנו: אל תתכננו מתוך Setup. עכשיו אתם מכירים סיבה נוספת. לחיצה על New Custom Object לא רק נותנת לכם טבלה; היא מחברת עוד חלק מהארכיטקטורה שלכם לפלטפורמה מונעת מטא-דאטה עם ריבוי דיירים. אבל לפני שמחליטים איזה אובייקט ליצור, יש שאלה בסיסית יותר: האם הנתונים האלה בכלל צריכים לחיות כאן? זה הבא בתור.

להרחבה

• 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.
• Salesforce Architects, Architecture Basics (opens in a new tab) (באנגלית, נבדק ב-2026-10-02, נבדק שוב ב-2026-10-12): מגבלות governor ומגבלות ריצה, כדי שקוד וטרנזקציות “לא ישתלטו על משאבי המחשוב המשותפים”.