עמודת קובץ מצורף SQL SERVER
-
(כל קובץ פיזי הוא בעצם ישות של רשומה בטבלה, אבל בדיסק...)
יש הבדל גדול בין מערכת ניהול קבצים שנבנתה מראש עבור כך עם ידע וניסיון של 50 שנה של החברות, ואפילו אינטל ו IBM עובדים במרוץ אדיר על מנת לייעל ביצועים. לבין מסד נתונים שתפקידו מוגדר שונה לגמרי.
השאלה כאן היא לא של ביצועים, כי קובץ הוא משאב הרבה יותר זול ממסד נתונים, השאלה היא אכן של ארכיטקרטורה כאשר התוכנה אמורה לנהל את אותם קבצים. אני למשל הייתי רוצה שכשמוחקים רשומה שמצביעה על קובץ, הקובץ יימחק, כלומר ליצור תמונת ראי בין הקובץ לדטה בייס בצורה אדוקה. ולעשות את זה כמובן עם טריגרים ולא בקוד של התוכנה הקדמית. כדי שגם כשנעשה שאילתה שתמחק מאות רשומות נוכל לסמוך על זה שזה מנוהל בצורה נכונה.
עדיין אין לי ניסיון מספיק, אבל ברור שהדטה בייס יתנפח להחריד אם נאחסן בו קבצים (כשמדברים על גירסת אקספרס זה מוגבל הרי ל 10 גיגה), אינדקסים עלולים להיפגע, ועוד שלל צרות. העניין זה הניהול המקביל של הקבצים מול הדטה בייס בצורה נאותה, כאן זה קצת קשה ליצור ארכיטקטורה אבל כנראה שלא תהיה ברירה.
פורסם במקור בפורום CODE613 ב24/02/2014 16:48 (+02:00)
-
השאלה כאן היא לא של ביצועים, כי קובץ הוא משאב הרבה יותר זול ממסד נתונים, השאלה היא אכן של ארכיטקרטורה כאשר התוכנה אמורה לנהל את אותם קבצים. אני למשל הייתי רוצה שכשמוחקים רשומה שמצביעה על קובץ, הקובץ יימחק, כלומר ליצור תמונת ראי בין הקובץ לדטה בייס בצורה אדוקה. ולעשות את זה כמובן עם טריגרים ולא בקוד של התוכנה הקדמית. כדי שגם כשנעשה שאילתה שתמחק מאות רשומות נוכל לסמוך על זה שזה מנוהל בצורה נכונה.
עדיין אין לי ניסיון מספיק, אבל ברור שהדטה בייס יתנפח להחריד אם נאחסן בו קבצים (כשמדברים על גירסת אקספרס זה מוגבל הרי ל 10 גיגה), אינדקסים עלולים להיפגע, ועוד שלל צרות. העניין זה הניהול המקביל של הקבצים מול הדטה בייס בצורה נאותה, [u:42t9jma1]כאן זה קצת קשה ליצור ארכיטקטורה[/u:42t9jma1] אבל כנראה שלא תהיה ברירה.
למה קשה ליצור ארכיטקטורה, כבר נתת את הפתרון לעשות כמין 'בינדיג' בין המסד לבין תיקיית האיחסון, ובינדיג זה צריך להיות חד כיווני רק מהמסד לתיקיה.
ובישביל זה יש את הטריגרים וכמו שאמרת שכאשר ישתנו ו/או ימחקו רשומות זה יעודכן בתיקיה, וכדי למנוע מחיקה בטעות של קבצים מהתיקיה אפשר להגביל את ההרשאות כמו שאמר דוד, וגם אפשר להגדיר את התקיה כנסתרת, ה attribute של זה הוא 2 כך שגם אם האקספלורר יציג תיקיות נסתרות תיקיה זו לא תראה [בדומה לתמונות שבאות עם קבצי mp3].פורסם במקור בפורום CODE613 ב27/02/2014 10:17 (+02:00)
-
בעצם השאלה שלי היא כך:
אני לא מדבר במקרה שהSQL יושב במחשב שיש לכולם גישה אליו ברשת המקומית, בכזה מקרה ברור שאני ישתמש בתיקיית רשת, ואולי גם יסתיר את התיקייה, וייתן למשתמשים כפתור שפותח את הקובץ בתוכנה שלו (קבצי וורד בוורד אקסל באקסל וכו').השאלה שלי היא במקרה דלהלן:
הDB יושב בVPS מרוחק.
המשתמשים ניגשים לDB המרוחק עם תוכנה (לא משנה כרגע איזה, מה שתבחרו NodeJS, WPF, Access וכו').
אני רוצה לצרף קבצים, לצורך הדוגמא הספציפית: קובץ וורד המכיל קו"ח של הלקוח.מהי הדרך הנכונה?
אני כותב תהליך שחשבתי לעשות:
- להעלות את הקובץ (FTP, או כל דרך אחרת), ולשמור אותו בשרת בתיקייה מסויימת, עם תבנית מסויימת. לדוגמא: הקובץ ייקרא 1,2,3 וכו' שזה המזהה הייחודי של הרשומה ללא כל סיומת.
- כשיבקשו אותו אני יוריד אותו (שוב FTP, WS או כל דרך אחרת) וישמור אותו בשם המקורי שלו.
- אחרי השמירה, אני יעלה את הגירסה המעודכנת לשרת.
לדעתכם זוהי הדרך, או לשמור בכזה מקרה את הקובץ בתוך הרשומה? (אין הרבה הבדל מהתהליך שכתבתי לעיל, רק להחליף את הFTP לשמירה פנימית - כל שאר התהליך נשאר.)
בנוסף, אני צריך לחשוב מה יקרה אם 2 משתמשים יערכו את הקובץ באותו הזמן, מי ידרוס את מי? (בגוגל דרייב [ונראה לי גם בסקי דרייב] פתרו את זה בצורה מאד מעניינת, ע"י שאתה רואה מי עוד עורך איתך את הקובץ, וגם את השינויים שהוא עושה.)
אולי בהמשך למה שארכיטקט הביא כאן, אפשר להשאיר את הקובץ ולשתף אותו עם גוגל דרייב או סקיי דרייב, ואז להציג את דף האינטרנט בתוך החלון של התוכנה, אבל זה לא כ"כ יעיל [כי גוגל דרייב לא עם תאימות מלאה לאופיס], וגם מתאים רק לקבצי אופיס, ואם נגיד שהמשתמשים ירצו לשתף קובץ פוטושופ ביחד - זה לא ילך.....
אז מה אתם חושבים?????
פורסם במקור בפורום CODE613 ב04/03/2014 00:39 (+02:00)
-
לדעתי במקרים רגילים מה שאמרת עם העלאה ושמירה במספור ואח"כ שמירה ללקוח עם שם מקור זה דרך נכונה.
בקשר לעריכה בו זמנית, אז באמת צריך לעשות נעילה בזמן ההורדה לעריכה עד סיום העלאה.זה נכון שלSQL SERVER יש מעלה בניהול אוטומטי של מנגנון הנעילות.
פורסם במקור בפורום CODE613 ב04/03/2014 09:22 (+02:00)
