עמודות וירטואליות
בשבוע הבא אני מעביר הרצאה בנושא פיצ'רים חדשים בבסיס הנתונים של אורקל 11 עם דגש על דברים שיכולים לעניין מפתחים של data warehouse. הפוסטים הקרובים יעסקו בנושאים שאני אציג בהרצאה.
עמודות וירטואליות הן עמודות מחושבות שמתנהגות כמו עמודות רגילות. הן אינן תופסות מקום בבסיס הנתונים ולכן ניתן להשתמש בכלי הזה בצורה נרחבת ביותר. מה שקורה בפועל כשמריצים שליפה עם עמודה וירטואלית הוא שהחישוב של תוכן העמודה מתבצע בזמן הריצה. יש לשים לב שמסיבה זו לא ניתן לערוך תוכן של עמודה וירטואלית.
עמודות וירטואליות ניתן להגדיר עם ערכים קבועים (constants), פונקציות דטרמינסטיות (כלומר שבהינתן ערך מסויים הן יחזירו תמיד את אותו הערך) או פעולות על עמודות מתוך אותה טבלה כמו פעולות חשבוניות או שירשור של עמודות. לא ניתן להגדיר עמודות וירטואליות על טבלאות זמניות (global temporary table) ולא ניתן להגדיר עמודה וירטואלית על עמודה וירטואלית אחרת.
על עמודות וירטואליות ניתן להגדיר אינדקסים (בדומה ל-function based indexes) ואפילו פרטישנים עם סייג מסויים: אם משתמשים בפונקציה דטרמיניסטית עצמאית (user defined) אז לא ניתן להגדיר פרטישנים.
שימושים אפשריים:
- עמודה מחושבת על סמך שתי עמודות (או יותר) מתוך הטבלה – לדוגמה חישוב שכר על סמך משכורת בסיס ועמלה שנמצאים בשתי עמודות שונות או שרשור של שתי עמודות – שם ושם משפחה.
- יצירת עמודה עם trunc לתאריך ברמות שונות מבלי להכניס את הערך לטבלה מספר פעמים.
- חלוקת הטבלה למספר פרטישנים לפי mod על עמודה מסוימת (נפוץ בחלוקת עבודה של אינפורמטיקה, לדוגמה).
דוגמה לאיך ההגדרה נראית ואיך משתמשים:
SQL> drop table zohar1;
Table dropped.
SQL> CREATE TABLE zohar1
(
a NUMBER,
b VARCHAR2 (20),
my_date DATE,
my_trunc_date DATE GENERATED ALWAYS AS (TRUNC (my_date)) virtual
);
Table created.
SQL> insert into zohar1 (a,b,my_date) values (1, 'aaa', sysdate);
1 row created.
SQL> select * From zohar1;
A B MY_DATE MY_TRUNC_DATE
---------- -------------------- ------------------- -------------------
1 aaa 24/11/2010 10:58:49 24/11/2010 00:00:00
בשביל מה, בעצם? קצת אבסטרקציה?
הרי אם החישוב נעשה בזמן ריצה, הייתי יכול לכתוב SQL שתעשה אותו הדבר ואותם ביצועים.
העניין הוא פחות עניין עיצובי ויותר פונקציונלי. ניתן למנות שני יתרונות בולטים (ואחד פחות).
היתרון הראשון הראשון הוא שאפשר לבצע מניפולציות על עמודות ולהתייחס אליהן כחלק מהשדות בצורה שקופה לאפליקציה – לדוגמה שרשור של שם ושם משפחה או חישוב מורכב אחר מבלי להזדקק ל-view מעל הטבלה בשביל להשיג את אותה פונקציונליות (זה הפתרון הקודם שהיו נותנים לאותה בעיה – כדי לאנדקס לפי פונקציה היינו שמים עם function based indexes). ההגדרה מראש של הפונקציה יוצרת מצב שבו לא משנה מי מנסה להכניס נתונים לטבלה, נעשית אותה מניפולציה על המידע מבלי להזדקק לטריגרים או רעה חולה אחרת ובחיסכון של מקום.
היתרון הבולט השני הוא בתחום הפירוטש (כלומר חלוקת הטבלה ל-Partitions) – כאשר שמים עמודה כזו בטבלה ניתן לפרטש את הטבלה לפי פונקציה וזה כבר יתרון אדיר שלא היה קיים בגרסאות קודמות. בגרסאות קודמות נאלצנו לשמור מניפולציות על השדה (trunc של תאריך, mod של מספר) וליצור את הפרטישן על העמודה הזו תוך כדי ביזבוז מקום בדיסק מצד אחד ואיכלוס השדה על ידי האפליקציה מצד שני.
היתרון הפחות בולט אך עדיין משמעותי: הוספה מאוד מהירה של עמודות מחושבות לטבלה (מכוון שאין צורך לעדכן את הטבלה בנתונים – רק להוסיף הגדרה). יתרון אדיר כשיש לך טבלאות עם מליוני ומילארדי רשומות.