היי, לאחרונה השאלה הזו עניינה אותי עקב מדריך שראיתי על MYSQL, למה בכלל להשתמש ב TRIGGERS? הדוגמא במדריך הייתה data validation ו logging וזה גם התשובות פה https://www.quora.com/Why-are-triggers-used-in-SQL , אז ל logging זה נחמד (*) אבל ל data validation הרוב ירצו לעשות את זה ברמת האפליקציה במיוחד כדי להחזיר שגיאה נורמלית למשתמש הקצה.


* ללוגים גם לא הייתי משתמש הרבה, לוגים שכתבתי מומשו ברמת האפליקציה כי רציתי לדעת מי משתמש הקצה שביצע את השינוי

עריכה: השאלה היא אם יש שימוש אחר ב triggers?

חתימתי העצומה בגודלה הוסרה ע"י השליט הבלתי מעורער שימי, למי שיש בעיה שיפנה אליו.


ד אַל תַּעַן כְּסִיל כְּאִוַּלְתּוֹ פֶּן תִּשְׁוֶה לּוֹ גַם אָתָּה. ה עֲנֵה כְסִיל כְּאִוַּלְתּוֹ פֶּן יִהְיֶה חָכָם בְּעֵינָיו

כל פעם שאתה רוצה שבעקבות שאילתא מסויימת יקרה משהו בצורה אוטומטית וללא צורך לנהל את זה באפליקציה.

האם אתה צריך את זה? לא יודע. כשתצטרך, תדע שזה קיים...

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

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

תודה על התגובה, אכן בתור backup זה אחלה, אבל שוב בד"כ (במיוחד למי שרגיל לעבוד עם Laravel שזה יחסית build in) יש עמודה של deleted_at.

אבל קרו לי מקרים שהייתי צריך למחוק לחלוטין (truncate) שוב אם זה backup אני נוטה יותר לעמודה deleted_at (הקונבנציה של Laravel)


אגב, מה החיסרון בלאפשר שאילתות DELETE למשתמש אפליקציה, אני מתכוון בדוגמא של שאתה באמת לא צריך את ה data יותר (אם יעלה על הדעת) משתמש קצה בסה"כ מסוגל לעשות מה שאפשרת לו, לא להזין שאילתות

חתימתי העצומה בגודלה הוסרה ע"י השליט הבלתי מעורער שימי, למי שיש בעיה שיפנה אליו.


ד אַל תַּעַן כְּסִיל כְּאִוַּלְתּוֹ פֶּן תִּשְׁוֶה לּוֹ גַם אָתָּה. ה עֲנֵה כְסִיל כְּאִוַּלְתּוֹ פֶּן יִהְיֶה חָכָם בְּעֵינָיו

truncate כחלק מלוגיקה אפליקטיבית? נשמע לי משהו נדיר ביותר... נשמע כמו משהו שיכול לקרות רק כשמשתמשים ב DB לא כדי לאחסן נתונים, אלא ב anti-pattern כלשהו כמו DB-as-IPC, DB-as-queue וכיוצ"ב (וגם אז נשמע כמו מתכון ל race condition אא"כ מנהלים נעילות בצד ודואגים לרמת מקביליות שהיא בדיוק 1), או אם משתמשים בטבלה ואז מרוקנים אותה כדי בעצם להשתמש בטבלה זמנית, במקום להשתמש ב... טבלה זמנית

החסרון הוא שאם יש לך באג בקוד, בין אם הוא קורה ספונטנית, ובין אם הוא קורה בגלל בעיית אבטחה (SQL Injection וכיוצ"ב), אי אפשר באמת למחוק את המידע[*], בטעות או בכוונה, וכל שתצטרך כדי להחזיר אותו, הוא לאפס את ערך טור ה deleted...

[*] צריך אבל לחשוב גם על update, שגם הוא כמובן יכול למחוק מידע. בהתאמה, ניתן למזער נזקים על ידי הגבלת המשתמש האפליקטיבי לאיפשור update רק לטורים שבאמת צריכים אותו. ואפשר לעבוד גם בתור append-only: אף אחד לא יכול לעדכן, אף אחד לא יכול למחוק - כל הזמן רק מוסיפים, וכשקוראים את המידע, קוראים את הנתון האחרון. כך, בעצם, גם אם פרצו לאפליקציה לגמרי, הנזק מוגבל לנזק זמני - אם אתה מוחק את הרשומות שנוצרו אחרי הפריצה, המצב חוזר לקדמותו, מבלי שתצטרך לחזור לגיבוי אחרון (שמי יודע מתי הוא היה וכמה מידע הלך לאיבוד בינתיים. וכן, לחכמים שקוראים את זה, אני יודע מה זה point in time recovery. לא כולם יודעים, לא לכולם יש, וכו'.)

נמאס לכם לזכור סיסמאות? לחצו כאן!

תודה על המענה.

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

נ.ב על טבלה זמנית אתה לא יכול לעשות self join (לפחות ב MYSQL) ככה שגם במקרה כזה במקום להשתמש בטבלה זמנית הייתי משתמש בטבלה אמיתית, וגם עשיתי את זה בפרודקשן (לא אמור להתגאות בזה אולי?) במקרה שבו כן השתמשתי בטבלה זמנית הייתי צריך שתי טבלאות זמניות כדי לעשות SELF JOIN

חתימתי העצומה בגודלה הוסרה ע"י השליט הבלתי מעורער שימי, למי שיש בעיה שיפנה אליו.


ד אַל תַּעַן כְּסִיל כְּאִוַּלְתּוֹ פֶּן תִּשְׁוֶה לּוֹ גַם אָתָּה. ה עֲנֵה כְסִיל כְּאִוַּלְתּוֹ פֶּן יִהְיֶה חָכָם בְּעֵינָיו

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

זה קצת נשמע לי כמו יותר בחירה בטכנולוגיה נוראית (node.js) מאשר הצדקה לביצוע לוגיקה אפליקטיבית שלא באפליקציה (see what I did there? אגב, יש לי דעה דומה על שמירת קבצים במסד נתונים במקום במערכת קבצים...)

אם הטכנולוגיה שלך לא מאפשרת לך לעשות משהו, אולי אתה משתמש בטכנולוגיה הלא נכונה... ולא, נדיר שיש one-size-fits-all (אני מסתכל אליכם, ג'אווהאיסטים!), הכוונה היא שכשהמערכת עושה משהו מורכב מספיק, זו לא מילה גסה להשתמש ב 2 טכנולוגיות/שפות שונות בהתאם לחלקי המערכת השונים. גם לא ב 4.

אתה אומר שצוות ה API לשכבת ה data עובר להיות צוואר בקבוק. ואתה מעביר את הבעייה ל DBA (איכשהו בדרך כלל מגיעים לצורך בDBA כשמתחילים להתעסק עם SP... לא?) אבל שם היא פתאום לא? זו אותה בעייה, אתה רק הולך איתה לסביבה עוד יותר מוגבלת, של DB, שלא רק שלא נועדה לזה, אלא גם כמות המפתחים שיודעים לעשות את זה טוב, קטנה בסדרי גודל... מה הסיכוי שזה יצא טוב אם זה טיפה מעבר למשהו סופר בסיסי?

השאלה היא למה אתה בכלל צריך להעביר מידע בין טבלה לטבלה? כאילו, אני יודע שיש מקרים שזה נחוץ לצורכי ביצועים בלבד, אבל לרוב, כשעושים דברים כאלה, זה פשוט מפתחים שחוטאים באי-הכרה של 3NF, ומשם מתחיל המדרון החלקלק של חברה שעוסקת כל היום ב data integrity במקום בלפתח פיצ'רים חדשים...

נמאס לכם לזכור סיסמאות? לחצו כאן!