Steve Data Modeling: מרשימות בחירה אל האינסוף ומעבר לו
מבוא:
ברוכים הבאים למפגש מעמיק נוסף על מידול נתונים בסדרה Steve’s Data Modeling! במאמר הזה נבחן את השימושים הרבים של רשימות בחירה (picklists), ונדון בתרחישים שבהם כדאי לשקול חלופות לדרישות מידול נתונים מתקדמות יותר.
הבנת רשימות בחירה
רשימות בחירה מושלמות כשיש לכם שדה שדורש קבוצה של ערכים קבועים. הן מציעות חוויית משתמש נקייה, אבל באות עם כמה מגבלות:
- הוספת ערכים דורשת הרשאות מנהל גבוהות.
- ערכים חדשים צריכים לעבור פריסה דרך סביבות sandbox.
שגיאות אימות נתונים מתרחשות אם ערכים שמגיעים מאינטגרציות של צד שלישי לא נוספו מראש ב-Salesforce.
אפשרויות לרשימות בחירה
הנה כמה אפשרויות לרשימות בחירה שכדאי לשקול:
אפשרות 1: קבוצות ערכים גלובליות
זו האפשרות הסטנדרטית של Salesforce, והיא יכולה לנצל רשימות על פני אובייקטים.
קבוצות ערכים גלובליות הן הטובות ביותר לערכים שמשמשים בכמה מקומות. לדוגמה, אפשר להחזיק שתי קבוצות ערכים גלובליות ל”קוטר הצינור” ול”עובי הצינור”, ולספק למשתמשים ממשק נקי לבחירת ערכים.
[caption id="" align=“alignnone” width=“1372”]
קבוצות ערכים לדוגמה [/caption]
[caption id="" align=“alignnone” width=“1814”]
ערכים לדוגמה [/caption]
[caption id="" align=“alignnone” width=“676”]
בחירה מתוך רשימה [/caption]
אפשרות 2: שדות טקסט
זה פשוט שדה טקסט בלי שום אימות.
אם ערכי הנתונים נדחפים דרך אינטגרציות, אפשר לשקול שדות טקסט. אבל בגישה הזו מאבדים את האימות, ומשתמשים יכולים להזין כל נתון, מה שעלול להוביל לחוסר עקביות.
זו יכולה להיות אפשרות אם השדות הם לקריאה בלבד ב-Salesforce ואתם רק מציגים את הערכים.
[caption id="" align=“alignnone” width=“678”]
אין אימות [/caption]
אפשרות 3: אובייקט ייחוס משותף
אפשר להשתמש באובייקט ייחוס משותף עם כמה סוגי רשומה לטעינות נתונים. הגישה הזו יוצרת שני קשרי lookup באובייקט הראשי, שמקשרים לאובייקט הייחוס במקום לערכים עצמם. אפשר גם להוסיף ערכים חדשים באופן דינמי בלי הרשאות מנהל, מה שמגביר את הגמישות.
[caption id="" align=“alignnone” width=“1462”]
שימוש בסוגי רשומה [/caption]
[caption id="" align=“alignnone” width=“1700”]
השתמשו ב-lookup מסונן [/caption]
[caption id="" align=“alignnone” width=“1434”]
הוספת ערכים [/caption]
[caption id="" align=“alignnone” width=“658”]
כך נראית בחירת ערך. המיון לא נכון, ולא כל הערכים מוצגים בטעינה הראשונה, כך שהמשתמש צריך לחפש אותם. ודאו גם שהסרתם את “Create” מהפרופילים ומערכות ההרשאות, כדי שמשתמשים לא ייצרו רשומות נוספות תוך כדי עבודה. [/caption]
חלק 3: אפשרויות מתקדמות
לתרחישים מתקדמים יותר, שקלו את האפשרויות האלה:
אפשרות 4: מסכים מותאמים אישית עם אובייקט ייחוס
אם אתם משתמשים ב-Lightning Web Components (LWC) מותאמים אישית במסכי העריכה, אפשר להשתמש באובייקט ייחוס כדי לקרוא ערכים ולהציג אותם, ולשמור את הערכים עצמם במקום קשרי lookup.
אפשרות 5: אובייקטים עצמאיים
אם החשיבות של ערכי ה-lookup גדלה, שקלו ליצור אובייקטים עצמאיים לכל אחד מהם וקשרי lookup נפרדים. הגישה הזו מאפשרת הוספה דינמית של נתונים, שומרת על מודל נתונים נקי, ותומכת בשדות קשורים נוספים בכל אובייקט.
דוגמאות מעשיות
הנה דוגמאות מעשיות שממחישות כל אפשרות:
רשימות בחירה סטנדרטיות: מציעות ממשק נקי עם ערכים קבועים.
שדות טקסט בלי אימות: מספקים גמישות, אבל בלי אימות נתונים.
Lookup לאובייקטי ייחוס: משתמש באותו אובייקט עם סוגי רשומה מסוננים לגמישות.
אובייקטים עצמאיים: משתמשים באובייקטים נפרדים לכל lookup, ומציעים מודל נתונים נקי וגמיש.
סיכום
הבנת הדקויות של רשימות בחירה ושל החלופות שלהן חיונית למידול נתונים אפקטיבי. מרשימות בחירה סטנדרטיות ועד אובייקטים עצמאיים, כל אפשרות מציעה יתרונות ייחודיים שעונים על צרכים מסוימים במידול נתונים.
חזרו בקרוב!
לתובנות ולטיפים נוספים, הישארו איתנו כאן ב-www.SteveTechArc.com ובערוץ ה-YouTube @SteveTechArc (opens in a new tab). הירשמו ושדרגו איתנו את הברק שלכם במידול נתונים!
עוזרים לשנות את העולם בשיתוף רעיונות מגניבים עם עמיתים ארכיטקטים ועם מי שנמצאים במסע שלהם לארכיטקטורה!
STA 2.2