none
TSQL RRS feed

  • שאלה

  •  היי לכולם,

     השאלה שלי היא כזאת : הגיע מנהל חדש לעבודה  והוא כותב IINER JOIN  בדרך הישנה מ  oracle

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

    לעבוד עם INNER JOIN  אז אשמח לשמוע הצעות איך אני משכנע אותו טאולי בכלל זה בסדר איך שהוא עובד.

    שרון.

    יום שלישי 01 נובמבר 2011 07:41

תשובות

  • מבחינה מעשית אין הבדל עקרונית (בהנחה שכותבים שאילתה זהה) וניתן תמיש לבדוק את תוכנית ההרצה שנוצרת כדי להיות בטוחים, אבל בפיתוח יש גם מעבר ל"עובד/לא עובד"!

    אופן כתיבת קוד מצביע הרבה על מי שכתב את הקוד!

    כתיבת קוד ארוך או קצר, כתיבת קוד המתאים ל ReUse או כתיבה מחדש, קוד כפול ועוד הרבה מאוד דברים שרואים בקוד שכותב מפתח

    לעבודה עם JOIN על כל סוגיו (...inner/left/right) יש מבנה אחיד ונקי כאשר כותבים באמצעות ON ולא מדובר בעיניין של שיטה חדשה יותר או ישנה יותר (שיטות ישנות יותר לא בהכרח גרועות יותר... אני סומך על שאילתות שאני כותב ידנית "בשיטה הישנה" הרבה יותר מאלו שנכתבות שלי על ידי ה ORM בשיטה החדשה של EF למשל). ניתן להגיע לדברים שבהשוואה ישירה הרבה יותר קשה להגיע בצורה מפורשת (קשה הכוונה כאמור ארוך או מורכב ולא קושי פיזי למי שיודע). עם הזמן כשהוא יכתוב שאילתות מורכבות יותר הוא יעשה שימוש  JOIN בשיטה עם ON כאשר יעשה שימוש למשל בסוגי JOIN אחרים כמו LEFT, אז למה לא להתאפס על דרך אחת נקייה ולא לכתוב קוד במספר דרכים שונות?

    * אני לא הייתי זוןרק מישהו שכותב ככה וגם לא היתי משקיע על זה הרבה מחשבה אם הוא שולט גם באופן הכתיבה הנפוץ יותר כל עוד הוא מצליח להגיע לתוצאה המבוקשת (לא מבחינת הנתונים שחוזרים רק אלא גם מבחינת יעילות).

    ** כל מה שנכתב הוא על בסיס נסיון/דעה אישית ואינו מהווה אסמכתה או קביעה! לכן מדובר בנושא שהוא פתוח לדיון וקשור לגישה ודעה (שוב אני מדגיש כל עוד התוצאה זהה) ולנושא אופן כתיבת קוד וארכיטקטורת פיתוח.


    signature
    • סומן כתשובה על-ידי sharonof יום שלישי 01 נובמבר 2011 09:25
    יום שלישי 01 נובמבר 2011 08:18
    מנחה דיון
  • 1. בכל הדוגמאות באינטרנט וב-BOL מקובל להשתמש ב-Join.
    הוא יהיה חייב בכל מקרה להכיר את הסינטקס הזה.

    2. מתכנתי SQL Server רגילים להשתמש ב-Join. הוא מתכוון לחנך את כולם לעבוד בשיטה "האוראקלית"?

    3. יש יתרון בשימוש ב-Join בכך שהתנאים המבטאים את הקשרים בין הטבלאות מופיעים ב-On,
    והפילטרים מופיעים ב-Where; וכך הקוד יותר קריא והקשרים בין הטבלאות ברורים.
    בשיטה שלו הכל מופיע ב-Where וקשה להתמצא. 


    Geri Reshef http://gerireshef.wordpress.com
    • סומן כתשובה על-ידי sharonof יום חמישי 03 נובמבר 2011 14:03
    יום שלישי 01 נובמבר 2011 19:54
  • זמן לימוד בסיסי של אופן כתיבה כזה או אחר של JOIN לאיש מקצוע ממוצע לא אמור להיות להערכתי יותר מחצי שעה (לפני שנים לימדתי את זה בקורסים בשיעור אחד של 45 דקות). עוד שעה שעתיים של תרגול עצמי והוא אמור לשלוט בכך גם אם לא לזכור בע"פ כל אופציה. אני לא אמליץ מה לעשות אם הוא לא יכול ללמוד תוך שעתיים שלוש את כל הנושא אבל אני יודע מה אני הייתי בוחר לעשות (הדבר נכון לגבי העובד החדש שאמור ללמוד את המצב הקיים ולגבי העובד הקיים שאמור ללמוד את שיטת העבודה עם ON).

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

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

    * יכול להיות שבע"פ הייתי אומר עוד משפט או שתיים של המלצה שאני נמנע מהן על גבי הפורום :-)


    signature
    • סומן כתשובה על-ידי sharonof יום חמישי 03 נובמבר 2011 14:04
    יום רביעי 02 נובמבר 2011 05:17
    מנחה דיון

כל התגובות

  • מבחינה מעשית אין הבדל עקרונית (בהנחה שכותבים שאילתה זהה) וניתן תמיש לבדוק את תוכנית ההרצה שנוצרת כדי להיות בטוחים, אבל בפיתוח יש גם מעבר ל"עובד/לא עובד"!

    אופן כתיבת קוד מצביע הרבה על מי שכתב את הקוד!

    כתיבת קוד ארוך או קצר, כתיבת קוד המתאים ל ReUse או כתיבה מחדש, קוד כפול ועוד הרבה מאוד דברים שרואים בקוד שכותב מפתח

    לעבודה עם JOIN על כל סוגיו (...inner/left/right) יש מבנה אחיד ונקי כאשר כותבים באמצעות ON ולא מדובר בעיניין של שיטה חדשה יותר או ישנה יותר (שיטות ישנות יותר לא בהכרח גרועות יותר... אני סומך על שאילתות שאני כותב ידנית "בשיטה הישנה" הרבה יותר מאלו שנכתבות שלי על ידי ה ORM בשיטה החדשה של EF למשל). ניתן להגיע לדברים שבהשוואה ישירה הרבה יותר קשה להגיע בצורה מפורשת (קשה הכוונה כאמור ארוך או מורכב ולא קושי פיזי למי שיודע). עם הזמן כשהוא יכתוב שאילתות מורכבות יותר הוא יעשה שימוש  JOIN בשיטה עם ON כאשר יעשה שימוש למשל בסוגי JOIN אחרים כמו LEFT, אז למה לא להתאפס על דרך אחת נקייה ולא לכתוב קוד במספר דרכים שונות?

    * אני לא הייתי זוןרק מישהו שכותב ככה וגם לא היתי משקיע על זה הרבה מחשבה אם הוא שולט גם באופן הכתיבה הנפוץ יותר כל עוד הוא מצליח להגיע לתוצאה המבוקשת (לא מבחינת הנתונים שחוזרים רק אלא גם מבחינת יעילות).

    ** כל מה שנכתב הוא על בסיס נסיון/דעה אישית ואינו מהווה אסמכתה או קביעה! לכן מדובר בנושא שהוא פתוח לדיון וקשור לגישה ודעה (שוב אני מדגיש כל עוד התוצאה זהה) ולנושא אופן כתיבת קוד וארכיטקטורת פיתוח.


    signature
    • סומן כתשובה על-ידי sharonof יום שלישי 01 נובמבר 2011 09:25
    יום שלישי 01 נובמבר 2011 08:18
    מנחה דיון
  • היי פיתוח,

    הבעיה שלי היא כזאת :

    עכשיו מגיע משהוא חדש לעבודה שלא מכיר את הסגנון הישן של  כתיבת SQL

    והוא צריך להתחיל להבין מה רשום ( למרות שביננו זה די ברור:) ועכשיו צריך לעבוד left join

    בפרצדורה  צריך לשנות כל השאילתה.....

    זה קצת בעייתי לא?

    תודה מראש שרון

     

    יום שלישי 01 נובמבר 2011 09:28
  • 1. בכל הדוגמאות באינטרנט וב-BOL מקובל להשתמש ב-Join.
    הוא יהיה חייב בכל מקרה להכיר את הסינטקס הזה.

    2. מתכנתי SQL Server רגילים להשתמש ב-Join. הוא מתכוון לחנך את כולם לעבוד בשיטה "האוראקלית"?

    3. יש יתרון בשימוש ב-Join בכך שהתנאים המבטאים את הקשרים בין הטבלאות מופיעים ב-On,
    והפילטרים מופיעים ב-Where; וכך הקוד יותר קריא והקשרים בין הטבלאות ברורים.
    בשיטה שלו הכל מופיע ב-Where וקשה להתמצא. 


    Geri Reshef http://gerireshef.wordpress.com
    • סומן כתשובה על-ידי sharonof יום חמישי 03 נובמבר 2011 14:03
    יום שלישי 01 נובמבר 2011 19:54
  • זמן לימוד בסיסי של אופן כתיבה כזה או אחר של JOIN לאיש מקצוע ממוצע לא אמור להיות להערכתי יותר מחצי שעה (לפני שנים לימדתי את זה בקורסים בשיעור אחד של 45 דקות). עוד שעה שעתיים של תרגול עצמי והוא אמור לשלוט בכך גם אם לא לזכור בע"פ כל אופציה. אני לא אמליץ מה לעשות אם הוא לא יכול ללמוד תוך שעתיים שלוש את כל הנושא אבל אני יודע מה אני הייתי בוחר לעשות (הדבר נכון לגבי העובד החדש שאמור ללמוד את המצב הקיים ולגבי העובד הקיים שאמור ללמוד את שיטת העבודה עם ON).

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

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

    * יכול להיות שבע"פ הייתי אומר עוד משפט או שתיים של המלצה שאני נמנע מהן על גבי הפורום :-)


    signature
    • סומן כתשובה על-ידי sharonof יום חמישי 03 נובמבר 2011 14:04
    יום רביעי 02 נובמבר 2011 05:17
    מנחה דיון
  • לדעתי תגיד לו שיש נהלי כתיבה.

    וכידוע עם נהלים אי אפשר להתווכח.

    והנהלים אומרים שיש לכתוב כמו שאתה חושב.

    אני חושב שברגע שתסביר לו שאלו הנהלים הוא לא ייקח באופן אישי ויתיישר עם נהלים אלו

    יום רביעי 02 נובמבר 2011 07:29