DataReader מול DataSet

[tberger]

DataReader מול DataSet

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

 

[gilad g]

תשובות ../images/Emo13.gif

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

DataReader לא משמש לשמירת נתונים בכלל, אלא רק לקריאה חד-כיוונית שלהם, מה גם שאי אפשר להשתמש ב-DataReader ללא Connection. הconnection חייב להיות פתוח כל זמן שאנחנו קוראים נתונים מ-DataReader. בקשר לאפליקציית WEB עם הרשימה של המשתמשים - בשביל זה יש ViewState. אחרי שממלאים את ה-DataGrid בנתונים, הנתונים נשמרים (אצל הלקוח!) ב-Viewstate, וככה ניתן להשתמש בנתונים האלו שוב ושוב. אם לא נוח לשמור נתונים ב-Datagrid (אני מודה, זה די עקום) - אפשר לשמור אותם ב-Dataset שנשמר ב-Viewstate. להשתמש באותו אובייקט עבור כל המשתמשים

זה יכול להיות רעיון נחמד - כלומר, אפשר לשמור את ה-dataset במשתנה application, אבל בשביל זה בעצם יש מסד נתונים. לדעתי כדאי לשמור נתונים ב-Application רק בתנאים הבאים:

אם הם משותפים לכל המשתמשים

אם התדירות בגישה אליהם גבוהה מספיק, כך שזה יצדיק את השימוש ב-Application ולא במסד נתונים.

אם הם לא משתנים בתדירות גבוהה מידי. הממ, זה בעצם מה ש-Output caching עושה

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

 

[tberger]

שאלת הבהרה

כלומר DataReader הינו רק כעין מתווך בין ה DB לפקד? לא ניתן להשתמש בנתונים שלו אלא רק לעשות לו BIND לאוביקט אחר ששומר את הנתונים?

 

[gilad g]

לא ../images/Emo13.gif

DataReader הוא בדיוק כמו Recordset לקריאה חד-כיוונית בלבד. אפשר בהחלט להשתמש בנתונים שלו, וגם לעשות Bind לפקדים אחרים - אבל החסרון הגדול שלו הוא שה-connection חייב להיות פתוח כל זמן העבודה איתו. כמו Recordset

 

[tberger]

כלומר

ברגע שסוגרים את ה CONNECTION האוביקט נעלם? לא ניתן לפתוח לסגור ולפתוח שוב אלא רק לפתוח לקרוא נתונים ואחרי שסוגרים אם רוצים לקרוא שוב את הנתונים יש ליצור אוביקט חדש?

 

[gilad g]

בערך..

ברגע שסוגרים את ה-Connection , ע"י conn.close(), אם מנסים לאחר מכן לקרוא מה-DataReader, הוא זורק Exception, כלומר מתרחשת שגיאה. "לא ניתן לפתוח לסגור ולפתוח שוב אלא רק לפתוח לקרוא נתונים ואחרי שסוגרים אם רוצים לקרוא שוב את הנתונים יש ליצור אוביקט חדש? " כן

אבל, DataReader יכול להתמודד עם כמה טבלאות (לא בו-זמנית). ראה NextResult. המתודה הזאת אומרת ל-DataReader, לעבור לטבלה הבאה שהוחזרה, במידה ויש לנו יותר משאילתת SELECT אחת (מופרדת ע"י נקודה-פסיק).

 

[גרי רשף]

הערות../images/Emo22.gif

בכל מה שקשור לעבודה מול בסיסי נתונים, הגישה ב- ADO.Net היא שמתחברים לבסיס הנתונים, מעבירים לזכרון את הנתונים איתם רוצים לעבוד, עובדים איתם במנותק מבסיס הנתונים, ובמקרה הצורך מעדכנים את בסיס הנתונים בסוף בשינויים השונים שנעשו. כלומר- יש צורך ב-Connection בהתחלה (לקריאה מבסיס הנתונים) ובסוף (לעדכון בסיס הנתונים), ובשאר הזמן הוא יכול להיות סגור. זה בניגוד ל-ADO הרגיל בו ה-RecordSet היה מקושר לבסיס הנתונים וכל שינוי בו (למשל בפקודת עדכון כמו Rs.Update Rs(I),531) היתה מעדכנת בדרך כלל את בסיס הנתונים. DataReader הוא נתונים שנקראו לקריאה בלבד ללא אפשרות לשנותם, דבר המקל על השרת והלקוח, ואז יש צורך ב-Connection רק לקריאה ולאחר מכן הוא מיותר.

 

[גרי רשף]

אופס, צ"ל: Rs.Update Rs(I),531

 

[mngr]

תסביר בבקשה

מה הרעיון של ה- DATASET בדף ASP.NET הרי במילא אני לא אשמור את ה-DATASET בין POST ל- POST, אני אצטרך כל פעם להקים אותו מחדש, אז במה הוא משפר את סביבת ה- ASP.NET (אני מבין את היתרון שלו בסביבה של Windows.fom) אלון

 

[gilad g]

../images/Emo35.gif

"הרי במילא אני לא אשמור את ה-DATASET בין POST ל- POST" -- למה לא

אפשר לשמור אותו ב-ViewState... אתה במילא שומר DataGrid שלם, אז במקום לשמור אותו, תשמור את ה-DataSet, ובכל פוסטבאק תעשה DataBind ל-DataGrid

 

[mngr]

זה לא ניפוח מיותר?

נניח שיש לי 2000 לקוחות, אני יוצר על השרת dataset ומחבר אותו ל-datagrid עם paging מה שאתה מציע זה לשלוח את (נגיד) 10 הרשומות של ה - page בdatagrid וגם את כל 2000 הרשומות בתוך viewState אל ה- CLient זה נראה לי ממש סירבול - מה דעתך?

 

[gilad g]

אז...

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

 

[mngr]

ואז

אני חוזר לשאלה המקורית - מה הטעם, אם המשתמש בוחר לעבור לעמוד הבא, אז הdataset ששמרתי כבר לא רלוונטי ואני צריך להקים אותו מחדש. בנוסף, בניגוד לwindows.form אתה לא עובד ממש על ה- dataset ונראה לי שכל הקונספט הזה של ה-dataset ב- ASP לא רלוונטי. לדעתי עדיף להתשמש תמיד ב- datareader ולעדכן את בסיס הנתונים ישירות עם אוביקטים של command לפי הצורך. אני לא רואה את היתרון של שימוש ב- dataset- אולי תוכל לאמר לי מה אני מפספס פה?

 

[gilad g]

אתה לא מפספס כלום ../images/Emo13.gif

אני מסכים איתך, באמת ב-ASP.NET המגמה היא יותר (לדעתי, לפחות) להשתמש ב-DataReader/Command ולא ב-DataSet.

 

[gilad g]

לעומת זאת

אם אתה מפתח N-Tier Application, יותר נוח יהיה להשתמש ב-DataSet.

 

[Admini]

לעומת זאת

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

 

[mngr]

לא הבנתי -

אתה תומך בשימוש ב- dataset או ב- datareader?

 

[Admini]

אין לך דבר שאין לו שעה

ואין לך דבר שאין לו מקום (מסכת אבות) יש מקרים שאני מעדיף את הראשון ויש מקרים שאני מעדיף את השני. כל דבר לגופו.

 

[danistar]

בכל הקטע הזה

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

 

[gilad g]

אתה יכול להרחיב../images/Emo35.gif