שאלת מבנה

[eyal7773]

שאלת מבנה

שלום,

יש לי אפליקציה שעובדת ברוב הטבלאות מקומית מול אקסס
ובחלק קטן מאוד מול MS SQL SERVER (מאוחסן וובי)

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

עכשיו הלקוח מבקש שכל אחד ממשתמשי הקצה יוכל לעבוד מכמה מחשבים עם סינכרון דרך האינטרנט
אני שוקל 2 אפשרויות - ואשמח לדעתכם (על האפשרויות שהצעתי , או רעיון אחר) :

1. העלאה של ה-DB המקומי (אקסס) ב-FTP לשרת
חיסרון : מהירות
יתרון : הכי פשוט לביצוע

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

מה דעתכם ?

 

[כלליים]

...

את האפשרות הראשונה לא הבנתי.

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

 

[lj101]

עדיף לך לאחד את הנתונים...

פיתרון אפשרי שתכתוב קוד שמייצא את הנתונים למאגר אחד ואז תחליט את אלו שדות אתה מייצא
תוסיף מזהה ייחודי למשתמש ב-SQL

כך שאם תוסיף נתונים המבוססים על משתמש תוכל ליצור מפתח לפי משתמש.

 

[eyal7773]

תודה רבה - זה כנראה הכיוון

אני אחליף את המפתחות הראשים המספריים - במפתחות אלפא-נומרים שמבוססים על שם המשתמש שיצר את הרשומה
וכך אוכל לסנכרן

תודה

 

[lj101]

לגבי גישה לנתונים ע"ג האינטרנט...

אני כתבתי פעם קוד ASP שישב בשרת אינטרנט ואז מהאקסס הייתי שולח שאילתות ומקבל את התוצאה כ-XML.

במקרה שלי אני עבדתי עם אקסס כדטה בייס וזה עבד בלי בעיות.

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

 

[eyal7773]

תודה על הרעיון, אבל זו בעיה פתירה

בעיקרון אני שוכר כמה Hosted SQL servers בכל מיני מקומות בעולם.

בשרת הנוכחי , הוא יושב בארה"ב - הוא גירסת 2008 ומריץ בערך 600 דאטאבייסים על שרת יחיד (חזק, אבל יחיד)
שזה כמובן לא מאפשר עבודה ב-Access linked tabled כי כל שאילתא אורכת קרוב ל-7 שניות
אז אם יש מסך אם כמה ComboBox באקסס - זה לוקח לו קרוב לדקה לעלות, שזה זמן לא סביר להמתין.

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

בכל מקרה, תודה על הנכונות.

 

[pitoach]

אייל כמה נקודות שאולי יעזרו

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

* כש lj101 דיברת על עבודה עם ASP אז הוא התכוון כניראה בדיוק למה שאתה מדבר עליו. אם שימוש ב ADO או בחיבור מסוג SQLCLIENT או כל שיטה אחרת הרי שהרעיון הוא שימוש בחיבור לשרת דרך אפליקציה חיצונית, ואז עובדים עם שאילתות רגילות בצורה מהירה. ה ASP מספק את הממשק GUI לצורך העניין (ASP טכנולוגיה לפיתוח מערכות רשת בדומה ל ASP.Net בעקרון זה).

* ממש ממש לא מומלץ בדרך כלל לעבור לשימוש במפתחות שמבוססים על שם המשתמש! הרבה יותר נכון בדרך כלל לעבוד עם מפתחות מבוססים ID של המשתמש ולהמשיך לעבוד עם טור נומרי (אם אין הרבה משתמשים אפשר אפילו smallint).

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

* מה שלוקח לאקסס הרבה זמן בחיבור הוא החלק המקביל לשימוש ב linked server. הסיבה היא בדרך כלל שהחיבור כולל את כל ההגדרות והבדיקות ומה שמסביב שלא מבוצע בחיבור ישיר. לכן openrowset הרבה פעמים הרבה הרבה יותר מהיר מ linked server.

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

* השיטה הראשונה שהעלת נשמעת כמו משהו שצריך לשכוח ממנו אלא אם מדור על סינכרון קבוע של למשל פעם ביום. לא הגיוני בדרך כלל הלעביר את כל הקובץ בשביל כמה רשומות שיש בו. במקרה זה הייתי עובד דווקא עם אפליקציה מקשרת בדומה למה ש lj101 דיבר עליו. אפליקציה מקומית שיושבת על כל מקום שיש בו את האקסס ותפקידה יהיה לבצע חיבור את השרת המרכזי ועדכון שלו ישירות מהאקסס המקומי. אני מאוד ממליץ לחשוב על כיוון כזה בפתרון סופי לבעיה. במקרה זה גם אפשר לבצע את הסי נכרון בצורה קלה בלי בעיה של שימוש בשם המשתמש אלא פשוט בכל אפליקציה מקומית יוגדר ID מקומי לטובת המפתחות בשרת המרכזי. האפליקציה מתחברת למשל ב ADO ובמצעת עדכון וסכרון מול השרת המרכזי.

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

* לסיום כרגע: אלגוריתמים כמו שאתה מדבר עליו בכלל אינו מורכב. השימוש בשרת מרכזי מאוד נפוץ. אם אתה עובד עם SQL 2012 אז החיים הרבה יותר קלים ואפשר לעבוד עם sequence ואם אתה עובד עם גרסאות קודמות אז אתה יכול לממש sequence לבד (היה על זה דיון בפורום של MSDN ושמתי הסבר מלא כיצד לממש sequence בשרתים ישנים יותר בצורה יעילה). או פשוט עובדים עם טור נוסף של ID המשתמש (השרת המרוחק. האקסס או מה שיש לך). המפתח יהיה מורכב מ 2 הטורים ... אני מניח שזה מה שהתכוונת לעשות בכל מקרה אז נסיים כאן להיום

 

[eyal7773]

המון המון תודה

על התשובה המפורטת

 

[eyal7773]

עוד שאלה לגבי מפתח ראשי

כאשר אתה אומר ש - "ממש לא מומלץ מפתח אלפא נומרי"

האם אתה מתכוון בכל מקרה ?

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

וכאשר זה מגיע ל-SQL Server - זה כבר שרת, ואף פעם אין גישה לכלל הרשומות.

אז למה זה כל כך גרוע ?

 

[pitoach]

המילה תמיד לא קיימת בלקסיקון של איש מקצוע

הכל תלוי מצב ותנאים ואפיון מערכת באופן כללי

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

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

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

מה זה אינדקס ומה הרעיון שלו?!? האם אינדקס משמש אותנו כאשר אנחנו ניגשים לכל הנתונים בטבלה? מתי ההשפעה של אינדקס יותר גדולה בגישה לנתון בודד או בגישה לחצי מהנתונים בטבלה? כמה אינדקס יעזור לנו כאשר אנחנו רוצים לגשת לחצי מליון רשומות לא רציפות מתוך 10 מליון רשומות? נניח שרשומה כוללת טור בודד של טור המפתח. נסו לבצע חישובים תיאורטים מעט. כמה IO השרת יפעיל אם יהיה לכם אינדקס נומרי וכמה אם זה אינדקס טקטואלי וכמה בלי אינדקס? אני מאוד ממליץ ל DBA שלכם לעבוד מול תוכניות הפעלה של השרת ולהבין מה קורה מאחורי הקלעים קצת לפני שהוא מקבל החלטות.

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

 

[eyal7773]

אוקי, תודה

 

[pitoach]