oracle tidbits: the trouble with triggers

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

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

Once upon a time, a long time ago, 

 I thought triggers were the coolest thing ever and I used (and abused) them heavily. Now, whenever possible, I will go very far out of my way to avoid a trigger.

וחייבים לתת לו את זה - הוא מאוד משכנע.

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

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

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

המפגש בין ההמלצה על חידושים לעומת ההמלצה לא להשתמש בטריגרים גרמו לי להרהר בחלק מהחידושים של Oracle של השנים האחרונות שאני מאוד לא אוהב. אני מדבר על אפשרויות כמו עמודות נסתרות או חלק מהטכנולוגיות החדשות שמנהלות מאחורי הקלעים מבנים שלמים (זה נכון כמובן גם לגבי אפשרויות שאינן קשורות לקוד, דוגמת ALTER TABLE...SET UNUSED שיש לי חשד שתשאיר אחריה הרבה מאוד מידע שלא נמחק אבל נשכח.)

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