SP vs. Sql

[orenphp]

SP vs. Sql

רציתי להעלות לדיון ויכוח מעניין שיש בין הגורסים בשימוש גורף בSP(stored procedures) ולבין יצירה של SQL ברמת הקוד של האפליקציה. אני גורס בעובדה שלכל הדברים ה"פשוטים" (כגון פעולות CURD פשוטות) צריכים להתבצע באפליקציה שכן אין חסכון בביצועים (בתכל'ס, לא מאמינים לי אתם מוזמנים לגגל ולראות) והרבה יותר קל לי לבצע שינויים (בהתאם לאופן שבו כתבתי את האפליקציה כמובן). בנוסף, יש הרבה פעמים שצריך למשל לבנות את הWHERE במשפט ואז להריץ את השאילתא, בsql server 2000 לא ראיתי פתרון קל לבנייה של הSQL חוץ מלהריץ פקודה של execute בתוך הSP (אם כבר אני מעדיף להריץ את זה באפליקציה). לדברים מסובכים, כגון ביצוע join-ים רבים ומסובכים כדאי לבצע אותם בSP(מבחינת ביצועים) על אף שגם פה קשה לבצע בנייה דינמית לשאילתא ואז חוזרים לפסקה הקודמת שכתבתי. לסיום, הייתי רוצה להעלות כאן לינק לויכוח שמצאתי בנושא שבהחליט היה מעניין(שותפים בשיחה שם מספר אנשים חזקים מאוד מעולם הdotNet) לטעמי: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx מה דעתכם בנושא ?

 

[liortm]

תגובה

דעתי בנושא היא שכדאי להשתמש ב-SP לדברים שהם יותר מורכבים מ-select, כמו למשל טעינת קבצים לבסיס הנתונים או מימוש איזשהו תהליך עסקי כבד שכולל הרבה עיבודים ופניות לבסיס הנתונים. לגבי joins מסובכים זה דבר שניתן לממש ב-view ואז בקוד ניתן לבצע selectעל אותו view.לגבי שאילתות דינמיות אני מסכים איתך שאין טעם לממש ב-SP., ולסיום אני מצרף לינק מהקומונה ששם עלה הנושא של מיצוב ה-SP במערכת שמפותחת לפי שכבות. לינק מהקומונה.

 

[ניר טייב]

SP שומר את המבנה הלוגי של השאילתא

כך שהוא לא צריך להתפרש כל פעם מחדש. לגבי מה שאמרת עם ה-where וה-execute אז יש לך טעות. אתה יכול ליצור משתנה ולהשתמש בו בשאילתא הרגילה שלך:

WHERE [tTable].[fField]=@yourVar​

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

 

[ניר טייב]

+ חוסם פרצות אבטחה

ע"י שימוש ב-SP אתה יכול להיות שקט שלא יהיה לך SQL Injection. נגיד ואתה עובד עם ADO באפליקציה שלך. אז יש אובייקט בשם ADODB.Command עם האובייקט הזה אתה יכול להעביר מידע לתוך ה-SP שלך מבלי שתהיה יכולת למידע שלך לשנות את השאילתא שלך.

 

[orenphp]

זה לא באמת לא סיבה.

שימוש נכון בParameters (בעולם הdotNet לפחות, בו אני כרגע נמצא) ימנע גם כן Sql injection ובאופן כללי, מודעות לבעיה בד"כ תוביל למציאת פיתרון אבל זו בטח לא סיבה למה לבחור האחד על פני האחר.

 

[orenphp]

כמה דברים.

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

 

[Gaus]

שאלה של צורת עבודה...

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

 

[ייוניי]

לא מאמין ב SP

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

 

[ניר טייב]

חבל...

הסבר מעולה לנושא: http://www.tapuz.co.il/tapuzforum/main/ForumFAQAnswer.asp?id=130&QID=132 אני בטוח ב-100% שתקבל הסבר ראוי ומשכנע על למה להשתמש ב-SP באפליקציה שלך אם תשאל בפורום בסיסי נתונים, יש שם כמה DBAים מעולים ל-MSSQL.

 

[guznik]

זה בדיוק כמו הויכוח בין C++ ל-Java

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

 

[Gaus]

צודק ב100% ../images/Emo45.gif

 

[ניר טייב]

ואם נחלק את הבסיס נתונים גם לשכבות

נגלה שהשכבה הראשונה היא השכבה של הטבלאות והקשרים ביניהם. השכבה השנייה היא ה-SP וה-VIEWS שבעצם מקשרים בין האפליקציה עצמה לבין הטבלאות. מה יותר קל ונוח: שיש לך תשתית מוכנה או שאין לך ?

 

[guznik]

לא הבנתי למה זה טוב

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

 

[orenphp]

לחלוטין חולק עליך.

הלינק שצירפת מראה למה DBA נותן סיבות בשביל שתיהיה לו עבודה. אם תקרא את הלינק שצירפתי בהודעה הראשונה (תסתכל בתגובות למאמר) תראה שכל סעיף שם הוא פשוט לא נכון. SP יהיה מהיר יותר רק(!) לפעולות כבדות ובשביל פעולות CURD פשוטות אין הבדלים בביצועים. אני יכול לתת לך טענה סותרת לגבי כל אחד מהדברים שצויינו באותו לינק, אבל הייתי רוצה שתקרא את הלינק שפירסמתי פשוט כי על כל הסעיפים שהעלת יש תשובה פשוטה שסותרת אותה. במיוחד הייתי רוצה שתקרא את התגובה של Paul Wilson שם, מה שהוא כתב שם זה הagenda שלי בנושא הזה (מניסיון ומחשיבה מעמיקה).

 

[ייוניי]

הדוגמא שיש שם

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

 

[שלמה שוורץ]

יש לי נסיון רב בנושא

היה לנו מוצר די כבד עם כמה עשרות SP כתובים בSQL SERVER. חלק מהפרוצדורות היו די ארוכות והתפרשו על פני כמה עמודי קוד SQL. כשהיינו חברת סטארט-אפ הכל היה טוב ויפה וכולם היו מרוצים. יום אחד נמכרנו לSAP (וככה הגעתי לסאפ...) כמובן שפתאום היינו צריכים להתאים את התוכנה לאוראקל וכבר התחילו דיבורים על DB2 ועוד דאטה בייסים. העבודה הסזיפית האינסופית היתה נוראית. חלק מהדברים שנתמכים בSQL לא נתמכו באוראקל או להפך. נאלצנו לפתח שכבות שלמות ובגרסאות הבאות היינו צריכים לתחזק שני סקריפטים ענקיים (אחד לכל דאטה בייס). פשוט סיוט! המסקנה שלי: כשיש שאילתות מאוד ארוכות שלוקח להן הרבה זמן להתקמפל ולרוץ - עדיף לעשות SP כי באמת יש לזה יתרון. ב90% מהמקרים כשמדובר בINSERT או SELECT רגיל עדיף לעשות את הלוגיקה בתוכנה ולא להשתמש בDB. גם דברים כמו "מיספור אוטומטי" ושדות כמו תאריכים ושעות עדיף מאוד לעשות באפליקציה (תחשבו על תמיכה בתאריכים עבריים ב5 דאטסבייסים שונים...) הגרסה האחרנה של המוצר כתובה בג'אווה משתמשת בדאטהבייס מינימלי ביותר. אומנם הפלטפורמה של הDB לא נכתבה בארץ אבל כשאני מסתכל אני רואה משהו כמו 10 טבלאות (בניגוד למאות במוצר הקודם) ואולי 4-5 פונקציות. אגב, שלא תטעו מדובר בDB לא קטן - מגיע בקלות לג'יגה בייט.

 

[Gaus]

יש לשאוף תמיד למינימום DB

 

[ניר טייב]

הפוסט לא ממש שכנע אותי

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

 

[ייוניי]

עוד נסיון שכנוע...

1. "עם SP: מגדירים יוזר שיש לו הרשאות הרצה ל-SP ובתוך ה-SP עובדים בתור DBO - ובכך אין אפשרות לפריצה." - לכל יוזר יש הרשאה להריץ כל SP שעולה על רוחו? לא נשמע לי מאוד מאובטח... אני חושב שהרשאות הן עניין אפליקטיבי עם נגיעות סיסטמיות. הדרך להגיע לאבטחה משופרת בכל מה שקשור ל DB היא להגדיר קודם כל שאין לשום יוזר הרשאות לעשות שום דבר ואז להגדיר בקוד האפליקציה "דרישות" ל DBA (או כל איש SYSTEM אחר) להרשאה לבצע פעולות על ה DB. ההרשאות יכולות להיות מאוד אטומיות: הוספה בלבד, מחיקה בלבד, צפיה ב VIEW בלבד וכו'... קצת קשה לי לראות איך SP שעושה בדיוק את אותה פעולה שאתה רוצה להגן עליה יכולה לעזור. לגבי תשתית שיותר נוח לעבוד איתה, ספר לי על זה כשתיתקל בשינויים גדולים במבנה הנתונים ב DB ותצטרך לקרוא ולהבין מחדש עשרות SP-ים. או כשתצטרך לתחזק SP של 300 שורות קוד כי מישהו החליט לחזור לימי ה FORTRAN...

 

[galh]

מה הקשר?

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