לוגו אתר Fresh          
 
 
  אפשרות תפריט  ראשי         אפשרות תפריט  מבזקים     אפשרות תפריט  צור קשר     חץ שמאלה ‎print ‎"Hello World!"; if‎ ‎not rules.‎know ‎then rules.‎read(); חץ ימינה  

לך אחורה   לובי הפורומים > מחשבים > תכנות ובניית אתרים
שמור לעצמך קישור לדף זה באתרי שמירת קישורים חברתיים
תגובה
 
כלי אשכול חפש באשכול זה



  #2  
ישן 20-07-2019, 21:28
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,489
בתגובה להודעה מספר 1 שנכתבה על ידי Nati323 שמתחילה ב "למה להשתמש ב triggeres ב SQL?"

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

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

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

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

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #4  
ישן 24-07-2019, 07:47
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,489
בתגובה להודעה מספר 3 שנכתבה על ידי Nati323 שמתחילה ב "תודה על התגובה, אכן בתור..."

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

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

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

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #6  
ישן 21-10-2019, 20:05
  rpi rpi אינו מחובר  
 
חבר מתאריך: 05.02.17
הודעות: 909
לא מכיר ארגון מורכב שמתבסס על db רלציוני מרכזי שהצליח להמנע מטריגרים
בתגובה להודעה מספר 2 שנכתבה על ידי שימי שמתחילה ב "כל פעם שאתה רוצה שבעקבות..."

אתה צודק לגבי הבעיות והסיכונים. מצד שני יש הרבה יתרונות כשיש שילוב של קבוצות פתוח וריבוי אפליקציות איזוטריות במערכת מרכזית.
אני לא ממש מפתח אבל יוצא לי בשנים האחרונות לעבוד גם עם גופים מבוססי node.js ומאוד מתסכל אותי היעדר היכולת שיש בטריגרים היות ואני תמיד מעדיף להעביר כמה שיותר עידכוני מידע אוטומטיים לשרת (שזה אומר להוריד מידע מהקליינט) מסיבות שונות כמו להקטין מאמצי אבטחה ומאמצי סינכרון בקליינט.
גיליתי שפיתוח עדכון מידע לטבלאות "אחרות" באמצעות טריגר באורקל יקח חצי יום, לעומת יומיים בפונקציונליות מקבילה בסביבת node.js. משהו נוסף לא בהכרח קשור, תופעה שראיתי בכמה מקומות: צוות ה Api לשכבת הדטה הופך להיות צוואר בקבוק משמעותי ושינוי api לעדכון נתונים עם לוגיקה אפליקטיבית לוקח ים של זמן. אני לא מתיימר להיות מומחה בעניין אבל תוהה אם מישהו השווה פעם או מצא פתרונות לסביבת node.js שמתחרה ביעילות פיתוח טריגרים באורקל.
תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #7  
ישן 21-10-2019, 21:31
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,489
בתגובה להודעה מספר 6 שנכתבה על ידי rpi שמתחילה ב "לא מכיר ארגון מורכב שמתבסס על db רלציוני מרכזי שהצליח להמנע מטריגרים"

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

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

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

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

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
תגובה

כלי אשכול חפש באשכול זה
חפש באשכול זה:

חיפוש מתקדם
מצבי תצוגה דרג אשכול זה
דרג אשכול זה:

מזער את תיבת המידע אפשרויות משלוח הודעות
אתה לא יכול לפתוח אשכולות חדשים
אתה לא יכול להגיב לאשכולות
אתה לא יכול לצרף קבצים
אתה לא יכול לערוך את ההודעות שלך

קוד vB פעיל
קוד [IMG] פעיל
קוד HTML כבוי
מעבר לפורום



כל הזמנים המוצגים בדף זה הם לפי איזור זמן GMT +2. השעה כעת היא 02:09

הדף נוצר ב 0.20 שניות עם 10 שאילתות

הפורום מבוסס על vBulletin, גירסא 3.0.6
כל הזכויות לתוכנת הפורומים שמורות © 2020 - 2000 לחברת Jelsoft Enterprises.
כל הזכויות שמורות ל Fresh.co.il ©

צור קשר | תקנון האתר