שלום, אני עכשיו עובד על פרוייקט המשלב הרבה מאוד תמונות.
אני צריך לעלות את התמונה לDB.
אני יודע שאפשר לעלות רק את המיקום של התמונה(זה מצה שעשיתי).
אני משתמש ב ASP.NET ו C# בצד שרת וSQL.
בDB עצמו יש אפשרות לטיפוס נתונים image ואין לי מושג איך אני מעלה תמונה לשם.
כדי לעלות את התמונה אני צריך שאילתת INSERT , אך אני צריך את התמונה בתוך משתנה(מה שאני לא יודע איך עושים).
אם אני צריך לפנות לפורום ASP.NET תגידו לי ואני יפרסם גם שם.
תודה

אם אתה כותב ב-DB רק את מיקום התמונה במערכת הקבצים, אז למה אתה מגדיר את השדה כטיפוס נתונים image? למה לא להגדיר את זה כמחרוזת\string\varchar ?
(שואל בתמימות, עד עכשיו השתמשתי רק ב-mysql)
להעלאת התמונה אתה צריך להגדיר את השדה כטיפוס בינארי ולהשיג את המידע של התמונה \ תוכן קובץ התמונה. בפורום ASP.NET יידעו מהי הפונקציה המתאימה, אני מניח שפונקציית קריאת קובץ (plain text) פשוטה תתאים...

דווקא טוב להשתמש image בתור שדה.

הDB מצפה לקבל ממך byte[] ז"א הDB מפרש אצלו ש imeag זה מערך של ביטים .

תוסיף לדף שלך פקד FileUpload של asp

כדי לקבל מהfileUpload את הbyte[] אתה פשוט שואב אותו בפקודה FileUpload1.FileBytes לתוך byte[] שתיצור או שתכניס אותו יישר לתוך הDB (את הFileUpload1.FileBytes) לתוך פקודת הINSERT שלך .

אני לא מבין למה אתה כותב ממש INSERTS למיניהם?
יש היום כלים שעושים את העבודה הזו בשבילנו כגון DataSet הישן לעבודה מול בסיסי נתונים או הADO.NET Entity Data Model (מVS2010 או בעדכון sp1 לVS2008)שממש הופך את כל הDB לישויות שניתן להתייחס בקלות. עבודה עם אחד הכלים האלו תעשה לך את החיים קלים (לדוגמא במקרה שלנו הוא היה אומר לך שהוא מצפה לקבל בתור תמונה מערך של ביטים ואת ההמשך הייתה מסתדר לבד (איך להמיר תמונה שמעלים לביטים...)

מקווה שלא חפרתי (התרגשות של תגובה ראשונה שלי בנושאים האלו)

ואתה מכיר סיבות טובות לשמור תמונה (כבינארי, ולא כמצביע לקובץ) ב DB?

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

תלוי מה מערכת מסד הנתונים שאתה משתמש.
ב MySQL יש לך את הטיפוס BLOB שהוא טיפוס שיכול לשמור תמונות בקלות.
הנה לינק לעבודה עם זה:
http://support.microsoft.com/kb/309158

רוב הסיכויים שב MS-SQL יש טיפוס דומה

שמע בעקרון זה תלוי באיזה גירסה SQL שלך. MICROSOFT החליטו שהחל מ SQL2008 לא יהיה טיפוס IMAGE יותר אלה רק VarBinary שאתה פשוט הופך את הקובץ תמונה ל רצף של בינארי ושומר אותו ב בסיס הנתונים. למה זה טוב? כי אם אתה רק שומר מצביע והתוכנה שלך עובדת ברשת נגיד עם כמה CLIENTS אז הם לא יוכלו לראות את התמונה דרך SQL כי היא לא נמצאת ב DATABASE ובגלל זה הכי פשוט להעלות הכל כקובץ BINARY וככה כל מי שמתחבר ל DATABASE בקלות יכול לשלוף את התמונה.

http://myspace.com/streetanimal

הלהקה הכי טובה בארץ!

הנה דוגמה לפונקציה שמעלה תמונה ל DATABASE :

http://www.digitalcoding.com/Code-S...SQL-Server.html

הנה דוגמה לפונקציה שמקבלת תמונה מה DATABASE:

http://www.digitalcoding.com/Code-S...sql-server.html

שוב אני למשל לקחתי את הפונקציות ושיניתי אותם שזה יתאים לתוכנה שבניתי.....

http://myspace.com/streetanimal

הלהקה הכי טובה בארץ!

בהמשך לדיון אם כדאי לשמור תמונות לDB :

http://stackoverflow.com/questions/...n-db-yea-or-nay
http://stackoverflow.com/questions/...-vs-file-system

שווה קריאה:
http://perspectives.mvdirona.com/20... sOfPhotos.aspx

עוד מאמר מעניין ממיקרוסופט :
http://research.microsoft.com/apps/...t.aspx?id=64525

אני הייתי מעדיף לדחוף הכל כמה שיותר לDB, אבל זה לאו דווקא צעד נכון.

אפרופו, ב MSSQL יש לך כזה : FILESTREAM

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

http://myspace.com/streetanimal

הלהקה הכי טובה בארץ!

1. אין שם המלצה באיזה שיטה לבחור, יש דיון, ושיקולים לשם ולשם.
2. אם אתה שומר בטיפוס הזה FILESTREAM, זה בדיוק כמו לשמור על הדיסק, אבל זה מוגש דרך הDB, אז לדעתי זה פתרון טוב מאוד.
3. לגשת לקובץ ברשת, זה אחד הפשוטים, זה כאילו דורש קצת תכנות, אבל בערך 7 דקות.

שוב, אין פה פתרון "נכון" יש שיקולים לטובת הראשון, ושיקולים לטובת השני.

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

once upon a time, המציאו אפליקציה מסויימת (שמעתי שקוראים לה "שרת Web") - שכל מה שהיא ידעה, זה לקבל שם קובץ, לשלוף אותו ממערכת הקבצים, ולזרוק אותו במהירות שיא אל הלקוח (בייחוד עם דברים חכמים שיש היום בקרנלים של מערכות הפעלה מתקדמות - כלומר - כל אלה שאינן "חלונות"...)

אין ספק שלערבב עוד 2 שכבות שמדברות אחת עם השנייה בדרך אל התמונה, זה גאוני. אם כל האתר שלנו איטי כי כתבנו אותו ב NET. על MS-SQL, למה באמת לעשות חצי עבודה? למה שהתמונות יעלו מהר? שגם הן יהנו מהאיטיות!

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

וכמובן, CDN - בכלל מילה גסה.

לסיכום - אצטט את אחת התגוובת שקראתי בדיונים שאליהם קישר hellfrost, קצרה וקולעת:

Data Base - For Data
File System - For Files

(ראית איזה יופי? בשם של הטכנולוגיה כתוב למה היא מיועדת!)

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

1. מה זה משנה אם אתה מעביר BLOB ברשת, או קובץ ברשת, איפשהו אתה חייב לטעון את הקובץ ולהוציא אותו, וזה לא ממש משנה איך הוא מגיע לשרת.
2. שימוש בFILESTREAM, ישמור תכלס את הקבצים, כאוספי קבצים בתוך תיקיות.
3. כן זה מגדיל את גודל הDB, אבל אין מה לעשות זה המידע שאתה שומר, והוא בד"כ גם ככה מופרד לקבצים בגדלים יותר סבירים.

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

למרות שאם הייתי בונה אתר או אפליקציית WEB כנראה הייתי מעדיף לזרוק את התמונות לדיסק. מצד שני אם הייתי בונה Middle Tier בישביל משהו יותר מורכב, כנראה הייתי זורק לDB. בכל מקרה ממש אין פה פתרון קסם יותר נכון.

1. משנה מאוד. להלן נתיב הגישה לקבצים בסביבה שלך:

דפדפן -> שרת ווב -> מנוע אפליקציה -> אפליקציה נטענת ומאותחלת -> כל הזבל שמגיע מסביב וצריך לעבד נטען גם הוא [דגש: סעיף זה רלוונטי רק בסביבות NET/Java.] -> אפליקציה פונה ל DB (שהרבה פעמים ירוץ על שרת נפרד, בייחוד כשהאפליקציה שלך כבדה מדי לרוץ עם DB, ע"ע NET/JAVA. שוב) בהתבסס על הפרמטרים שהתקבלו בבקשת ה HTTP -> ה DB מבצע Lookup ושליפה של הנתונים -> ה DB מכין את הנתונים לשליחה, ומחזיר אותם על חיבור ה TCP בינו לבין שרת ה Web -> שרת ה Web -> האפליקציה פורסת את הנתונים לתוך משתנה, בודקת מה גודלם ומה מאפייניהם, ופולטת את כותרי ה HTTP המתאימים -> האפליקציה מחזירה את הכל ביחד אל שרת ה Web -> שרת ה Web מחזיר לדפדפן.

עכשיו נשווה לשיטת מערכת הקבצים:

דפדפן -> שרת ווב -> שרת ווב מקבל נתיב -> פותח קובץ ישירות -> משתמש בפונקציית סיסטם מהירה כגון sendfile64() ושולח ישירות מה FD של הקובץ אל ה FD של ה socket.

מינימום העתקות. מקסימום ביצועים. מידע לא עובר סתם בין שרתים. הורדה דראסטית של כמות ה Single point of failure האפשריים. מאפשר ביזור ברמת DNS ושימוש קליל ב CDN-ים.

איך אומרים: Seems like a no-brainer to me, לא?

2. כלומר משתמשים באותה שיטה שאני משתמש בה, רק שיש עוד שכבת תרגום מיותרת באמצע? גאוני!!!

3. ודאי שיש מה לעשות. להשתמש במערכת קבצים כדי לאחסן קבצים...

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

לפני שאני עונה עניינית על מה שכתבת, אני לא מבין את הקטע שלך עם .NET ו JAVA, אתה רוצה שאני אביא בנצ'מרקים שבהם שתיהן לוקחות את PHP? אתה מודע לזה שJAVA יכול להגיע לביצועים יותר טובים מC++?
ומה זה "כל הזבל מסביב" אם אפשר לשאול?
יש יתרונות לכל פלטפורמה, וכמות האפליקציות שכתובות בJAVA וב.NET רק מראה כמה הזלזול שלך מגוכח.

1. שני התיאורים שלך לא נכונים. ושניהם יכולים לקרות בPHP .NET JAVA ASP או פייתון.
הראשון הוא:
דפדפן -> שרת ווב -> מנוע אפליקציה (שב99.9999% מהזמן כבר טעונה) -> אפליקציה פונה לDB טוענת את כל מה שהיא צריכה -> שרת ווב (שנמצא באותה עולם עם האפליקציה) -> חזרה לדפדפן.

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

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

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

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

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

שוב, זה לא שיש פתרון נכון, לאתר WEB, הפתרון של לשמור על הדיסק נראה לי עדיף, אבל זה ממש לא התרחיש היחיד....

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

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

כמות האפליקציות שכתובות בשתי הנ"ל בהחלט מוכרת לי. בייחוד בישראל, מדינת הגאונים.

1. איכשהוא פספסת את ה overhead בגישה ל DB שכאמור יושב בד"כ על מכונה אחרת ואפילו לא בהכרח על אותו LAN. או בכוונה, או ש... ?

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

2. זה כן משנה, כי יש לך IO הלוך וחזור מיותר בין האפליקציה ל DB. זה דורש משרת האפליקציה לבצע הרבה יותר טראנזקציות ממה שהוא צריך - ולחינם. אולי אתה חושב על אפליקציה שניגשים בה גג לקובץ אחד בשנייה. אני מדבר איתך על אתר אינטרנט שמספק גישה למאות/אלפי קבצים בשנייה וצפונה. אתה באמת חושב שיש איזשהוא מצב שבו זה רעיון טוב להעמיס את כל התעבורה הזו דרך האפליקציה שלך ודרך ה DB, עם כל רוחב הפס הנלווה, השיהוי, וכו', רק כדי ש... מה בעצם?

4. אשר להרשאות, אמרת בעצמך, אפשר דרך מערכת קבצים (איפה שרלוונטי...). אם אתה רוצה ברמה אפליקטיבית, אפשר לעשות סוג של security by obscurity, על ידי כך ששמות הקבצים יהיו בלתי אפשריים לניחוש (כמו סיסמאות) מלכתחילה, ואז רק מי שניגש לדף שנוצר על ידי המערכת ששמרה את הקבצים, ידע את מיקומם, וכך תנהל את ההרשאות אליהם. ושוב אני מפנה למערכת הקבצים האדירה של פייסבוק.

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

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

אשר לטראנזקציות, תעשה טראנזקציות ב DB ברמת ה metadata. אל תמחק קבצים (או תמחק אותם באופליין אם בא לך). תן שם חדש לקובץ אחרי שינויים, ואת הישן תפנה בזמנך הפנוי, אם בכלל תפנה. בד"כ ממילא יש דרישות ל archiving (שמעת על Sarbanes–Oxley?), אז אתה לא הולך למחוק בכל מקרה..

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

לא מפתיע שמיקרוסופט דוחפת את הכיוון הזה עם ה FileStream הזה שהזכרת. הם כבר ניסו פעם להפוך את מערכת הקבצים ל DB. רעיון מגוחך. קראו לזה WinFS. אתה זוכר מה קרה לזה בסוף? (אל דאגה, אני בטוח שבדרכם ל-ויסטה2 [סליחה, התכוונתי למילניום3], עוד יהיה resurrection לקשקוש הזה...)

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

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

2. תראה אני לא בטוח שאנחנו מדברים על אותו דבר. מה שאני משווה בראש זה שתי פריסות:
א. שרת ווב, שגם מריץ את האפליקציה, מאחוריו יושב בשרת אחר DB, וכל התמונות מאוחסנות בDB.
ב. שרת ווב, שגם מריץ את האפליקציה, מאחוריו יושב בשרת אחר DB (ובכל זאת רוב המידע, לאו דווקא בנפח, אבל רוב המידע שצריך להביא נמצא בDB), בנוסף וכנראה באותו Storage שיושבים בו הקבצים של הDB, בתקייה אחרת יושבות כל התמונות, והDB שומר רק את ה URIים שלהם.

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

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

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

ד"א דווקא בגלל CDN השיטה של לשמור נתיבים יותר קוסמת, כמו שציינת.

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

לגבי הWINFS, הם פשוט הבינו שמערכת קבצים זה גם ככה DB, רק שהוא היררכי, ו scheme free, בניגוד לרלציוני. אז אם פשוט מוסיפים לו INDEXING אפשר להגיע לפחות או יותר מה שהם רצו להגיע עם WINFS בהרבה הרבה פחות עבודה. אבל היי Microsoft Research צרכים לעשות תיזות... יש אפילו מערכות קבצים שהן עם דברים בכיוון של טרנזאקציות אההם Journaling...

מה אתה דפוק ? אפילו youtube ו RAPIDSHARE משתמשים ב SQL SERVER 2010 בשביל הקבצים הגדולים באמת!


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

http://myspace.com/streetanimal

הלהקה הכי טובה בארץ!

1. ^_-

2. לטעון תמונה ממשאב רשת ב.NET זה ממש קל, שורה אחת. לטעון כל דבר, מURI כלשהו, זה קצת יותר קשה, בערך 3 שורות

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

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

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

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

DBMS זה Data Base Managment System.... כאליו SQLSERVER, MySQL וכאלה, אין הבדל בצורה שאתה צריך לגשת לDB של טרה, או של מגה.

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

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

אין תשובה של כן או לא, אם זה מה שאתה רוצה...

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

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

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

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