שימוש ב-Synonyms

16/08/2015

תגיות: , , ,
תגובה אחת

נתחיל בסיפור (בפוסט הזה יש הרבה בלה-בלה-בלה ומעט קוד): בחברה שעבדתי בה לפני הרבה שנים הייתה מערכת CRM שישבה על אותו שרת כמו ה-DWH. לא בדיוק Best Practice, אך כפי שציינתי – זה היה לפני הרבה שנים, ומה שהיה נאה אז אינו יאה כיום.
באיזשהו שלה הוחלט להעביר את ה-CRM לשרת אחר, וכדי לא לשבש את כל תהליכי ה-ETL שפנו לדטבייס הסמוך (ETL? השתמשנו ב-DTS, למי שתהה כמה זה “לפני הרבה שנים”) יצרו בו בִּמקום טבלאות ה-CRM הישנות Views שפנו דרך Linked Server לשרת החדש. כלומר, אם פעם ה-DTS היה פונה לדטבייס CRM_DB לטבלה Customers_Tbl, כעת הוא פנה לאותו דטבייס אך ל-View בשם Customers_Tbl שהוא עצמו שלף את כל הנתונים דרך Linked Server מהשרת החדש.
כל התהליכים המשיכו לעבוד כסדרם, יתכן והיה לזה מחיר מה בביצועים (בכל זאת – פניה לשרת אחר דרך הרשת), אבל ה/מערכת נותרה יציבה ועבדה ללא דופי.

הדרך הנכונה יותר לבצע זאת היא תוך שימוש ב-synonyms, אותם יוצרים בערך כך:

Create Synonym MySyn For dbo.MyTbl;

ומאותו רגע ניתן להריץ מול MySyn פקודות Select או Insert וכו’. במקרה הצורך ניתן לציין גם את שם הדטבייס ואף את שם ה-Linked Server בהגדרה.
מה היתרון של Synonyms על פני השימוש הנ”ל ב-Views?

  • זה תפקידו של ה-Synonym, בעוד שבמקרה של View מדובר יותר באילתור. ניתן לבצע בעזרת ה-Views אילתורים כאלה וגם מורכבים יותר, אך במקרה זה עדיף Synonym שזה יעודו.
  • Synonyms יכולים להיות לא רק על טבלאות, אלא גם על פונקציות ופרוצדורות.
  • כאשר משתנה מבנה של טבלה (למשל- מוסיפים לה עמודה) יש לבצע sp_refreshview ל-Views שפונים אליה בעזרת * Select או לעדכן אותם אם הפנייה כוללת את שמות העמודות, אך ב-Synonyms אין בכך צורך.

במקום העבודה הנוכחי אנחנו משתמשים די הרבה ב-Synonyms: יש כל מיני דטבייסים שב-Prod הם בשרתים נפרדים ואילו בפיתוח באותו שרת, יכולים להיות דטבייסים שפעם הם על אותו שרת ופעם לא (כמו בדוגמה איתה התחלתי את הפוסט), וגם מקרים בהם לדטבייס כלשהו יש שמות שונים בסביבות שונות; וכדי להימנע משינויים בקוד הכלל הוא שכל פנייה לאובייקט בדטבייס אחר (לא כל שכן בשרת אחר) תיעשה דרך Synonyms, וכך אותו קוד רץ בכל הסביבות, וההבדל היחידי הוא בהגדרות ה-Synonyms.
כך, כשמעלים קוד מהפיתוח ל-QA ומשם ל-Prod יש לשנות רק את ה-Synonyms (אם יש),
ואם מעבירים דטבייס משרת לשרת יש לשנות את ה-Synonyms שפונים ממנו לדטבייסים אחרים ומדטבייסים אחרים אליו (הפרטים נמצאים ב-sys.synonyms).

מתי טוב להשתמש ב-Views? כאשר לא מדובר ב-Select * From פשוט אלא ב-Select על חלק מהעמודות, הוספת עמודה מחושבת, פילטור התוצאות (ע”ע Row Level Security), ביצוע Join עם עוד טבלאות או Group By וכו’.
מקרה אחר הוא כשיש מגבלות או בעיות בשימוש ב-Synonyms, למשל (דוגמה חמה מהתנור):
בדטבייס מסויים יש פרוצדורה שפונה לטבלאות בדטבייס אחר ב-Azure, כמובן – דרך Synonyms.
לאחרונה נחסמה הגישה משרת ה-Production לאינטרנט משיקולים בטיחותיים, וכעת לא ניתן לפנות ל-Azure, אך כן ניתן לפנות לשרת הרפליקציה שממנו כן יש גישה לאינטרנט. הפתרון היה אם כך להפנות את ה-Synonym שפונים ל-Azure לשרת הרפליקציה, ל-Synonyms שיפנו משרת הרפליקציה ל-Azure. מסיבה לא ברורה זה לא עבד, אלא רק כשיצרנו בשרת הרפליקציה Views שפנו ל-Azure (במקום Synonyms). שורה תחתונה: במקום Synonyms ב-Production שפונים ל-Azure, יש לנו כעת Synonyms ב-Production שםונים לשרת הרפליקציה, וממנו דרך View ל-Azure.

מה לגבי Security?

  • יש לתת הרשאות ל-Views & Synonyms: גם אם יש לנו הרשאה לקרוא מטבלה, לא ניתן לפנות אליה דרך View או Synonym אלא אם כן יש הרשאה עליו.
  • אם יש הרשאות על View או Synonym, ניתן לגשת דרכם לטבלה גם אם אין לנו הרשאות ישירות (אבל אך ורק דרכם!), וזה נקרא הורשה.
הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

תגובה אחת

  1. יוסף צור27/08/2015 ב 12:44

    הנה עוד סיבה להשתמש בviews:
    חלק מהORM [ובכלל זה entity frmaework] אינם יודעים לעבוד עם Synonyms.
    לדוגמא, כידוע כל מודל עובד מול דטהבייס אחד. ומה אם אנחנו רוצים לצרף למודל טבלה מדטהבייס אחר? הפתרון הוא ליצור View שפונה לטבלה הזו.
    במקרה הזה Synonym לא יעבוד, EF לא יכיר אותו, ותתחולל שגיאה.
    אגב: הORM של טלריק יודע לעבוד גם עם Synonyms.

    הגב