אולי אתם תצליחו

  • פותח הנושא ELIVB
  • פורסם בתאריך

ELIVB

New member
אולי אתם תצליחו

שלום חברים נסיתי בפורום בסיסי נתונים ובפורום NET, לא קבלתי תשובות אז אולי אתם תצליחו. יש לי בסיס נתונים ב SQL 2005 איזה סוג של שדה מתאים על מנת לשמור דפי אינטרנט בפורמט MHTML Document. אפשר לראות דוגמא באקספלורר דרך קובץ -- שמירה בשם --- Web archive single,שומר את כל הדף בקובץ אחד. גודל הקובץ הוא די גדול, אתר ללא צבע ותמונות מגיע לגודל של 250K. ובמידה ויש צורך לשמור אלפי דפי אתרים מדובר על בעיה. בהמשך האם לאחר שמירה של אתר בפורמט TXT יש אפשרות להציג את האתר בפורמט HTML בלי להפסיד מידע ולראות את הדף המקורי במידה ויש רעיון אחר אני אשמח לשמוע בתודה מראש אלי
 

user32

Well-known member
מנהל
חפש מידע על BLOB

כל בסיס נתונים מודרני תומך בBLOB - Binary Large Objects. אישית, אני מתנגד לשמירת "גושי" מידע בבסיס נתונים. נראה לי יותר נכון לשמור מצביע (מיקום של קובץ למשל) ואת המידע עצמו לשמור בקובץ על הדיסק. שמירה של HTML כטקסט תתן לך רק את התוכן והעיצוב. אתה מאבד את התמונות, סרטונים, פלאש וכו'. אם מדובר על אתר דינאמי שמשתנה בהתאם לבקשה אז הרבה פעמים אין טעם לשמור דפים.
 

hg1979

New member
נקודה מענינת

לצערי אין לי יותר מדי להוסיף כתשובה לשאלה המקורית, אבל בקשר ל"התנגדות" לשימוש ב BLOB ושימוש ב"מצביע" לקובץ במערכת הקבצים, זה מענין כי מנסיוני הלא קטן בנושא, עוד לא מצאתי מצב "מציאותי" שבו באמת היה יתרון אמיתי ומוצדק לשימוש ב"מצביע" ולא ב BLOB, הסיבות העיקריות שבחרו בפתרון ה"מצביע" הם כתוצאה : 1.מחוסר ידע (מה אפשר לשמור קבצים ב database ?) 2.חוסר הבנה (איך WORD ידע לפתוח את הקובץ מה database ?) 3.חוסר מחשבה לעתיד (אין לי הרבה קבצים אז אני לא רוצה סתם להשתמש ב database) והיו עוד סיבות שלא עולות לי לראש כרגע, בכל אופן (לא מציאותי, לפחות להגדרתי) יש מצב שבו באמת לא כדאי להשתמש ב BLOB, כאשר הקבצים הם בסדרי גודל של עשרות מגה בייטים, אז באמת התקורה של הקריאה מהבסיס נתונים עצמו מתחילה להטריד, אבל בינתיים לרוב המקרים (בטח למקרה של השאלה המקורית) זה לא רלוונטי
 

user32

Well-known member
מנהל
אתה סותר את עצמך

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

hg1979

New member
סליחה

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

itzikbs

New member
../images/Emo45.gif ובנוסף ...

דיון מעניין ... השאלה שנשאלה עסקה בפתרון לאחסון קבצים ב DB ואשר ב MSSQL2K5 קיבל עוד יותר כוח ותמיכה, בדמות של שדות Image/Text בעלי יכולת מניפולציות יותר מבעבר, אפשרות לייבוא וייצוא מהירות באמצעות SSIS כמו כן נוסף שדה מסוג XML שנותן פתרון טוב לשמירת דפי HTML או יותר נכון XHTML. כל מנגנון ופלט' MsSharePoint מושתת על שמירת כל הקבצים ב DB כולל תמונות, וורד, אקסל והכל תוך פעולות IO רבות... אז אני בהחלט מסכים עם הגישה שניתנה פה לגבי היכולות של אחסון קבצים ב DB כאשר בהרבה מקרים זה לא ידוע איך או שזה מסובך יותר מאשר סיבות מקצועיות. ביי איציק ב.
 

user32

Well-known member
מנהל
עדיין יש בעיה

אולי אנחנו חוזרים לוויכוח ישן שטחנו פה בפורום: מה עדיף לעשות בDB ומה עדיף לעשות בקוד? ככלל, יש לטראומה מסויימת מעבודה קודמת. כתבנו מוצר די רציני (בערך 60 מתכנתים) שעבד כולו על SQL Server וניצל את היכולות של SQL ופיצ'רים שונים. יום אחד החברה נרכשה והתבקשנו אחר כבוד לתמוך גם באורקל. הטירוף והעבודה הסזיפית והאינסופית שלא לדבר על תחזוק שתי המערכות גרמו לי לשנות את הגישה. את התוכנה הנוכחית שכתבתי (חברה שאני ייסדתי) התאמתי מראש לSQ, אורקל, MySQL, ואפילו אקסס ובעצם לכל DB רלציוני. זאת כיוון שהשתמשתי רק בSQL סטנדרטי ואת כל ה"גימיקים" של הDB כמו הרצת C# בתוך פרוצדורות, או כל אותם פיצ'רים יפים שitzikbs הזכיר השארתי בחוץ. טיפול בBLOB וXML למשל הם נושאים שמאוד מושקעים בSQL ואורקל אבל כל מוצר בה עם גישה משלו. אם אתה בטוח שלעולם תשתמש בSQL אז אולי שווה להשתמש בפונקצינליות של הDB, אבל לפעמים כדאי לחשוב קדימה. יש הרבה לקוחות (בעיקר גדולים) שירכשו מוצר בתנאי שהוא ירוץ על הלינוקס-אורקל שלהם ולא מוכנים בכלל לשמוע את השם MS SQL.
 

itzikbs

New member
"... ניצל את היכולות של SQL ..."

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

user32

Well-known member
מנהל
זה באמת מה שאני עושה

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