זה טוב במידה ויש לך ריבוי לקוחות שיש בינהם עולם משותף אך אתה רוצה להפיץ לכל לקוח נגזרת חלקית של העולם, ההבדל בין זה לממשק הרשאות לדוגמה, במידה ואחד הלקוחות רוצה לשנות קצת שמות או מושגים בעולם שלו שלא בהכרח מתאימים לאחרים וכו.
1.יש לך מבנה שמשותף לכל/או כמה עולמות בארגון ואתה גם רוצה לחסוך זמן פיתוח וגם לחסוך בזמן הפצת השינויים.
ב-Linked Universe אם שינית משהו בעולם core שלך ,כל שאר העולמות שעולם ה-core משולב בהם ישתנו בהתאם,אם משנים למשל משהו בהיררכייה הגיאוגרפית/לקוח ,Joins,הרשאות וכו'.
2.יש לך עולם גדול מאוד שכמה מפתחים עובדים עליו (מתי זה קורה...?) וככה כל אחד יכול לפתח את החתיכה היחסית ובסוף ניתן לשלבה בעולם אחד ומאוחד.
3.אם העולם שבנית מבוסס על מערכת שמשרתת לקוחות שמקבלים את התמיכה ממך אתה מפיץ להם את העולם ואז הם לא יכולים לעשות בו שינויים.
המגבלות בעולם שבו משולב עולם ה-core הם שלא תוכל לשנות שום דבר קיים אלא אם כן תבצע לו include או שתערוך פשוט את עולם ה-core,כן תוכל לבנות אובייקטים חדשים ותנאים ולהוסיף טבלאות.
בגרסאות קודמות היו אי אלו בעיות עם ה-LOV והקישוריות בין עולם המקור לעולם שבו הוא משולב,בגרסא xi3.1 העניינים יציבים למדי.
האם כדאי לי להשתמש בפונקציה הזאת כאשר אני מתכנן סביבה חדשה מרובת עולמות ?
כאשר יש לי אלמנטים משותפים הקיימים בכל עולם
(למשל - לפתח בעולם CORE את מימדי הלקוחות אשר יהיו בשימוש בכל אחד מהעולמות המקושרים?)
נניח לעשות עולם של פרטי לקוח,
וצריך לקשר את העולם של פרטי לקוח לעולם אחר במספר צורות,
פעם כפרטי לקוח , פעם כפרטי לקוח משלם, פעם כפרטי לקוח בעלים,
וכו'
למעשה את פרטי הלקוח צריך לקשר למספר טבלאות בעולם האחר ולכל טבלה בו מספר פעמים, על כל פרטיו עם כל האוביקטים שנילווים לו.
הייתי אומר שזו נחשבת פשוט גישה מאוד מאוד לא מקובלת לבעיה מסוג זה המצריכה קודם כל התייחסות ומחשבה מבחינת מודל הנתונים.
האופצייה שלנהל את העולם בכמה עולמות היא בעייתית,מסורבלת,קשה לתחזוקה וסוטה מרעיון העולם.
מבנה אחד יסודי ובסיסי לשאר העולמות מתאים ללינק לא ניהול של טבלאות alias בגלל מבנה בסיס הנתונים.
