SP vs. Sql

[שלמה שוורץ]

זה בדיוק העניין

אם אתה כותב ANSI אז אתה לא ממש יכול לכתוב SP. הSP מחייב אותך לכתוב בשפה של הDB הספיציפי. דבר שני, יש הרבה דברים שאתה יכול לעשות בקוד עצמו ולא בSQL ואז לחסוך תחזוק. במקום לעשות SP מלא בלולאות, תנאים ובדיקות אתה יכול להריץ רק את השאילות עצמן ואת הבדיקות והתנאים לכתוב באפליקציה עצמה. כל הרעיון של שימוש בUSERS של הDB לצרכי האפליציה נראה לי מקור אינסופי של בעיות ותקלות. כל דבר שאפשר להגן עליו בDB אפשר גם לעשות בקוד. הקוד מאפשר לך להיות הרבה יותר גמיש ועם יותר שליטה.

 

[ניר טייב]

כמובן שאפשר לעשות כך

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

 

[ייוניי]

טיולים בין האפליקציה למסד

הם דבר טוב וחיוני. ההפרדה ביניהם צריכה להיות מוחלטת על מנת למקסם את היתרונות של כל סביבה וליהנות מ scalability ומתחזוקה נוחה. ה DBMS היא בד"כ תוכנה די "כבדה" שיש לה מספיק עבודה של ניהול ה storage, האינדקסים, הדרישות לנתונים, פונקציות רלציוניות וכו'... למה להעמיס עליה תהליכי עיבוד שהיא לא חזקה בהם? (מערכת ההפעלה יעילה הרבה יותר). אם יש לך תהליכים כבדים שזקוקים לשיפור ביצועים אני אישית ממליץ על שפה שמתאימה ל Real Time כמו ++C שבעזרתה אפשר לכתוב תהליכים שמשתמשים ישירות ב API של ה DBMS והביצועים שלהם יעלו בכמה מידות על SP. אבל ב 99% מהמקרים אתה לא תזדקק לביצועים כאלה והריבוי ב SP-ים רק מעיק על ה DBMS שהוא בד"כ שרת בודד ודי מסכן, בניגוד לשרתי אפליקציה שיכולים להיות מרובים ומהירים בהרבה.

 

[ניר טייב]

אז כנראה זו גישה שונה בין

תכנות תוכנה לבין תכנות אתר. כאשר מתכנתים אתר רצים על מכונה הקרויה שרת (

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

ולכן אני בתור בונה אתר עדיף לי להשתמש ב-SP כך שאני מבצע גישה אחת למסד (כלומר טיול אחד) ולא אלפי גישות.

 

[ייוניי]

אין הבדל בין אתר לאפליקציה

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

 

[ניר טייב]

דוגמא כמו שניתתי למעלה(למשל)

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

 

[ייוניי]

הדגמאות שלך הן שוב תשתיתיות

ולא אפליקטיביות ספציפיות. אם נעסוק לרגע ב ADO (למרות ש ADO.NET פותר את הדברים בצורה קצת אחרת) את פעולת העדכן-או-הוסף-אם-אין אפשר לעשות בבדיקה פשוטה של EOF ושימוש ב AddNew על מנת ליצור רשומה חדשה במקרה שאין רשומה נוכחית, ולא מתבצעת פעולה נוספת מול השרת (אלא רק בקריאה ל Update) - חוץ מזה תמוה מאוד השימוש שם בטרנזאקציה מקוננת על מנת להוסיף את הרשומה... מה אם אני רוצה Rollback על הפעולה הזו?... חלוקה לעמודים, מציאת ID וכל שאר הפעולות ניתנות לביצוע בעזרת SQL נכון או אם תרצה על ידי SP תשתיתי כללי (!!!) ולא ספציפי לשליפה מסויימת או לאפליקציה מסויימת. אני חושב שהדיון הזה הגיע לרוויה מסויימת - אבל בהחלט יש כאן נקודות למחשבה למי ששואל את עצמו האם ומתי להשתמש ב SP

 

[ניר טייב]

אפשרי אבל זה עולה בביצועים

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

 

[ייוניי]

אתה טועה

בעקרון ADO מהיר בהרבה מ SP משום שהוא מקומפל לשפת מכונה ולא מתורגם כמו שפת הסקריפט שבה אתה כותב SP. ולא הבנתי את ההערה לגבי פתיחת ה Recordset כי אתה מבצע את אותה פעולה ב SP שבדוגמא... האמת היא שההתעסקות בביצועים כאן היא שולית מאחר ומראש אם היית מעוניין באתר WEB עם ביצועים משופרים היית כותב אותו בשפה מתאימה יותר לביצועים כמו ++C למשל ועובד מול ה DBMS בעזרת API מהיר יותר (כמו OCI של ORACLE למשל...) ולא ASP עם ADO. ובטח שלא עם SP שהביצועים שלהם ירודים מאוד מפני שהם "מנוהלים" על ידי מנוע ה DBMS שכמו שאמרתי עסוק גם ככה בהמון משימות אחרות. ובכלל, במערכות מידע עסקינן ולכן הבדלי ביצועים מינוריים כמו שאתה מזכיר כאן הם שוליים ביותר ולא מצדיקים את האנרגיה שבכתיבת קוד מחוץ למערכת...

 

[ניר טייב]

שמצבעים הכנסה מסכנה

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

oRs.Open("SELECT * FROM tbl",oCon,1,2,2) oRs.AddNew oRs("fld").value="'aaa' oRs.Update newId=oRs("ID").value​

ואפשר לעשות את כל זה בקריאה אחת ל-DB באמצעות SP.(בערך משהו כזה ב-TSQL)

BEGIN TRANS INSERT INTO(fld) VALUES("aaa") SELECT scope_identity() END TRANS​

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

 

[ייוניי]

הדברים שאתה מציג כאן הם מחוסר נסיון

תחשוב לרגע מעבר לצורך המיידי ואל תוך התחזוקה. הוספה של שדה במקרה של קוד ה ADO היא הוספה של שורת קוד בודדת. במקרה של SP אני כבר צריך לשנות שורה (שזה יותר גרוע מלהוסיף) להוסיף פרמטר, לשנות את הקריאה מהקוד וכו'... וכל זה רק בשביל פעולת הוספה פשוטה, אתה לא מתאר לעצמך כמה זה מורכב כשמדובר בפעולות מורכבות יותר שהועברו באופן לא חכם ל SP. ואם תחשוב על המובן היותר OO של העניין (למרות ש ASP לא ממש מאפשר OOP חזק) היכולת שלי לקחת את ה oRS הזה ולהעביר אותו בין פונקציות נוספות שיעדכנו שדות שונים לפני שאני מעדכן ל DB היא כוח רב מאוד. (אני יכול לעשות את זה עם Command ועם Parameters בקריאה ל SP אבל זה כבר נהיה ממש מוזר ולא נעים). לגבי בניית אתרים - אני כתבתי אתרים ב ++C ל WINNT לפני שהיה בכלל ASP והביצועים של ++C לעולם יהיו טובים יותר מאשר ASP מפני שהם מקומפלים לעומת דפי ASP שהם מתורגמים מחדש כל פעם (ויותר מ ASP.NET שאיננו מנהל זיכרון לעצמו). תהליך התרגום של ASP הוא בעל סיבוכיות גדולה בעשרות מונים מקריאות בין פרוססים (למרות שגם ++C אפשר להריץ בתוך הפרוסס של IIS). אבל אני מודה שזה מגוחך לדבר על ביצועים ברמה כזו במערכות מידע... אני ממליץ לך להתרכז יותר בשיפור תחזוקתיות ופחות בשיפור ביצועים כי את השני בד"כ אפשר לעשות בקלות בכל שלב ואילו הראשון - חבל על הזמן

 

[שלמה שוורץ]

מסכים בהחלט

אני זוכר שרת WEB שכתבנו בC שהיה רץ על WIN NT ונתן ביצועים מעולים. הוא עשה משהו דומה לASP וידע לקרוא דפים בשפה מסויימת שהמציאו אצלינו. עם IIS אפשר לכתוב C++ בסבבה דרך ISAPI פילטר וזה גם נותן ביצועים טובים. ASP בגלל השימוש בAutomation של COM מאט מאוד את הביצועים. הASP.NET זה בכלל סיפור, פחות או יותר אותן בעיות ביצועים שיש בג'אווה. לדעתי ברוב המקרים תחזוקה של SP היא תמיד יותר קשה מתחזוקה בקוד. ברור שSP לא נועד לתכנות אפילקציות שלמות, זה לא היה הרעיון שלו. זו בסה"כ דרך לשמור שאילתא מראש. לכן ברגע שאתה מעביר יותר ויותר לוגיקה של התוכנה לסביבה ענייה (אין OO והרבה דברים אחרים) אתה יוצא בסופו של דבר מופסד. והכי גרוע זה תחזוק SP בדאטה בייסים שונים, רק מי שעבר את זה יבין כמה זה מתסכל.

 

[ניר טייב]

ולך תתקין את אותו ISAPI על שרת

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

 

[ניר טייב]

הם לא מתורגמים מחדש בכל פעם

בשרת "נשמרת" גרסה "מקומפלת" שלהם. אני כבר כמה שנים טובות (כ-3 וחצי שנים, אמנם לא הרבה אבל מספיק בשביל לצבור ניסיון) בתחום בניית האתרים. כיוון שכמו שאמרת ASP לא מאפשר OOP חזק (זה לא ממש ASP אלא יותר השפות סקריפט שמשתמשים בהם, ו-JS שהיא אחת מהן כן מאפשרת OOP במידה מסויימת) אין לי את הצורך באותו רקורדסט בכמה פונקציות שונות. בעמוד אחד בד"כ עושים פעולה אחת של שינוי המסד (בד"כ) (נגיד הוספת הודעות בפורומים, או מחיקת פוסט בבלוג) ולא 20 פעולות על אותו רקורדסט (וטוב שכך). ולהזכירך, C++ לא נועדה לבניית אתרים.

 

[ייוניי]

אני לא פוסל את השימוש ב SP

אני פוסל אופן מסויים של שימוש. "ואם לא תעבוד עם SP ותממש את כל השאילתות בקוד, לא תצטרך ללמוד עשרות שאילות ולתחזק 300 שורות קוד?" לא, למזלי אני כותב קוד בשפה שהיא OO ולא זקוק לפרוצדורות של 300 שורות קוד. SP מאפשר תכנות פרוצדוראלי בלבד ומוגבל ולכן התחזוקה שלו קשה הרבה יותר מאשר קוד Java למשל. "אני תמיד אומר שמתכנת טוב זה מתכנת עצלן. אחד שמחפש קודם מישהוא אחר שיעשה את העבודה." שים לב שאני לא פוסל את השימוש ב DBMS וניצול היכולות שלו במערכות מידע. אני מעוניין ב cache, אני מעוניין בגיבויים וכל שאר ה"גימיקים". הדבר היחיד שלא נשמע לי חכם לעשות זה לכתוב קוד ספציפי לאפליקציה מסויימת כ SP מפני שלדעתי הדבר מוביל בהכרח לתחזוקה כפולה של קוד (לדוגמא הוספת שדה ב DB). לגבי שינוי התנהגות ללא קימפול - אני בעד, אבל בתנאי שאני לא צריך לפזר לוגיקה במקומות שונים לשם כך. הסיכון הוא שכל שינוי ב SP יגרור שינוי בקוד וההפך (תחזוקה כפולה), או יותר גרוע - לא יגרור שינוי בקוד אבל עוד כמה שנים כשמישהו ישנה את הקוד ה SP לא יתפקד כראוי ומישהו יצטרך ללמוד אותו מחדש.

 

[ניר טייב]

אז זהו שלא.

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

 

[שלמה שוורץ]

זאת הבעיה שלך

ניחשתי שאתה עובד עם MSSQL. גם אני עבדתי כך, עד שהגיע דרישה לעבוד גם עם אוראקל. לא שאוראקל פחות טוב (בהרבה מובנים הוא יותר טוב) אבל הוא שונה וזה מצריך שינויים גדולים ותחזוקה כפולה. היום אני תומך ב: Access, SQL, MYSQL, ORACLE ואולי יהיה גם DB2. תחשוב מזה קורה כשצריך לשנות או להוסיף SP...

 

[ניר טייב]

אני כבר הרבה זמן לא עובד עם מסדי

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

 

[ייוניי]

-->

"ברגע שיש לך שינויים גדולים במבנה של ה-DB יהיו לך שינויים גדולים גם באופן שבו האפליקציה שלך עובדת". נגיד שהוספתי 6 שדות לטבלה מסויימת אבל הם מוצגים רק ב 10% מהמסכים של המערכת. (אפשרי, לא?) אם אני עובד עם SQL לא שיניתי שום דבר ב 90% מהמסכים במערכת. מה קורה אם אני עובד עם SP? השדות ישלפו גם עבור אותם 90% ופשוט לא יוצגו? - לא טוב, עולה לי בביצועים. ליצור SP חדש עבוד ה 10%? - אז יש לי כפילות קוד ופעם הבאה אני מתחזק שני SP-ים. רעיונות נוספים? (תחשוב גם על ה SP-ים של העדכון... ותחשוב ששינוי כזה יכול להתרחש אחת לשבוע-שבועיים)

 

[ניר טייב]

ומה אם נגיד מחקת עמודה

מהטבלה ? עם SP אתה מתחזק רק במקום אחד ואילו ב-Dynamic SQL אתה צריך לעבור על כל האפליקציה שלך. בכל מקרה יש לך כפילות קוד. רק גדולה יותר, במקום רק פעמיים יש לך 10% מהאפליקציה אוי ותר גרוע 90% מהאפליקציה לשדרג.