עבודה נכונה מול מסד נתונים ללקוחות נפרדים
-
יש להבדיל בין שני סוגי מוצרים, מוצר רגיל ומוצר שניתן כשירות.
במוצר רגיל הלקוח משלם בד"כ סכום גדול פעם אחת והמוצר לרשותו (אמנם במהלך חיי המוצר ייתכן שהוא משלם סכום קבוע לתחזוקה, אבל היה תשלום חד פעמי שהקנה זכויות במוצר לתמיד או לפרק זמן גדול שהוגדר).
בכזה מקרה התפיסה היא שהמערכת שייכת לגמרי או במידה רבה ללקוח, וגם אין בעצם לבית התוכנה סיבה לערב לקוחות יחד כי זו לא מערכת אחת לשני לקוחות אלא שני מערכות שגם אם יישבו על אותה תשתית זה נטו לתועלת פרקטית של בית התוכנה על חשבון הסדר הטוב. כמו"כ זה פחות ראוי שהמערכת שתוכננה עבור לקוח A תעבור שינוי או כיפוף כדי לחיות יחד עם לקוח B.בתוכנה שניתנת כשירות, אז הגיוני לערב לקוחות יחד כי זה אותה מערכת. הגיוני גם שיצטרכו לבצע שאילתות "חוצי לקוחות" לצרכים סטטיסטיים לטובת המוצר, שהינו מוצר שלנו ולא של שום לקוח כי הלקוח רק שוכר את ההתנהגות והתוצאות.
משיקולי פרקטיקה, למסדים נפרדים יש מעלה של אבטחה, קלות של גיבוי ושחזור, ועוד דברים כאלו, ויש חסרונות של הפצת עדכוני סכמה וכדומה.
-
אני מחזיק מערכת שנבנתה בהתחלה עבור לקוח ספיציפי, ובהמשך הותאמה לעוד כמה לקוחות
כל לקוח מקבל דוקר עם מסד אישי שלו
כל המערכות משתמשות באותם קבצים של האפליקציה, עם משתני סביבה שמחברים אותם למסד הנכון
שינויים שאני עושה בקוד, משתקפים בכל המערכות
שינויים שאני עושה במסד, אני מריץ סקריפט באש שמבצע אותם בכל המסדים.
נכון שזה מצריך מעט יותר עבודה, אבל מצמרר אותי לחשוב שכל הקליינטים היו על אותו מסד, כמה התנגשויות היו יכולות להיות.
דוגמא פשוטה שעולה בדעתי, מספר טלפון של יוזר שאמור להיות ייחודי, אם אותו יוזר היה משתמש במקביל בשתי מערכות מה הייתי עושה?
כמה תכנון הייתי צריך לעשות כדי להמנע מהתנגשות כזו, וכמה עבודה זה היה מצריך לתחזק מערכת כזו
וגם לתחזק את השאילתות נראה לי מאד קשה, זה מחייב לזכור ולקחת בחשבון תמיד את ה ClientID, וטעות יכולה להיות הרת גורל -
@יוסף-בן-שמעון כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
טעות יכולה להיות הרת גורל
בהחלט משהו שלא חשבתי עליו, כלומר טעות לוגית בפיתוח (שזה משהו בלתי נמנע) עלולה לתת גישה של לקוח לאחר.
זה כמעט מוריד לגמרי את האפשרות הזאת מעל הפרק, אני כותב כמעט כי אולי אפשר לעשות איזה שכבת הגנה במסד או ביישום מתווך שיבטיח שכל משתמש עובד רק עם שורות שמתאימות לו, כרגע לא מכיר או לא מצליח לחשוב על דרך כזו. -
@יוסף-בן-שמעון
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?@dovid כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
בכזה מקרה התפיסה היא שהמערכת שייכת לגמרי או במידה רבה ללקוח, וגם אין בעצם לבית התוכנה סיבה לערב לקוחות יחד כי זו לא מערכת אחת לשני לקוחות אלא שני מערכות
וכל שינוי או פיצ'ר שרוצים להוסיף, צריך לעדכן אצל כל אחד באופן פרטני?
מותר לציין: שבעצם אם עושים שינויים לכל לקוח לפי דרישתו, אז גם אם מוסיפים משהו או שידרוג בתצוגה, זה דורש התאמה מיוחדת לכל אחד ואפי' רק העתקה לכל אחד לא יספק, כך באמת כל החברות עובדות? -
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?ההתרשמות שלי הוא שהרבה (אם לא רוב) ה-SAAS-ים לא עושים DB פר לקוח, אלא DB גלובלי אחד. ככה זה גם ב-SAAS-ים שאני עבדתי עליהם.
אפשר למצוא ברחבי הרשת דיונים על זה. ברור שמבחינת אבטחה יותר טוב לעשות מסד נפרד, אבל לעשות מסד גלובלי זו גם דרך לגיטימית.
לגבי הפחד מזליגה של מידע מלקוח ללקוח, ממה שראיתי בפועל זה לא חשש שצריך לשתק אותך, הפתרון הוא מודעות, ועם מודעות הסיכויים של באג חמור יורדים מאוד
אני מדבר בעיקר על שירותים שתוכננו מראש עבור הרבה לקוחות.
במקרה של השואל שזה נבנה בהתחלה עבור לקוח אחד ועכשיו מצטרף לקוח בודד נוסף אני יותר נוטה לכיוון של DB נפרד -
@yossiz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
לגבי הפחד מזליגה של מידע מלקוח ללקוח, ממה שראיתי בפועל זה לא חשש שצריך לשתק אותך, הפתרון הוא מודעות, ועם מודעות הסיכויים של באג חמור יורדים מאוד
אני מניח הנחה פשוטה:
- כל מפתח יוצר באגים,
- אחד לכמה באגים מגיע לפרודקשיין בטעות
- הסיכוי של באג להגיע לפרודקשיין לא תלוי בחומרתו בכלל, אלא בכמה הוא בולט וקל לתפיסה בקריאה או בהתנהגות. משפטי SQL יכולים להטעות מאוד כי הרבה פעמים משפט SQL שגוי אפילו באופן חמור יראה תוצאות שנראות בסדר גמור ברוב המקרים.
לפי הנחה זו איני יודע על מה אתה נשען, העובדה שמספיק טעות של שני תווים בערך (הן בSQL עצמו והן בקוד שאמור ליצור אותו) בשביל לעשות את הטעות,
היא לא "חשש" אלא סיכוי גבוה ביותר שזה יקרה, גם בזהירות קיצונית. המציאות היא שגם אני וגם אתה טעינו הרבה פעמים וירדו באגים שלנו לפרוקשיין. -
@dovid
הפחד מזליגת נתונים יכול להיות לך גם כשמדובר בלקוח אחד כאשר נציג פשוט יצליח לקבל נתונים של ניהול,
אתה צודק שזה אכן משהו שצריך לשמור מאוד חזק, אבל לדעתי זה לא סיבה לא להשתמש עם db אחד. -
@ivrtikshoret כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
הפחד מזליגת נתונים יכול להיות לך גם כשמדובר בלקוח אחד כאשר נציג פשוט יצליח לקבל נתונים של ניהול,
למרות שאפשר להגן על בית מגנבים גם אם יש בו חלון זכוכית, עדיין את כלל הקיר עושים בכל זאת מאבנים.
ההבדל הוא שהמקרה שלך הוא מקרה רגיש מלכתחילה ונקודתי, ממילא קל לבודד ולהיזהר בחוליות הרגישות ולמקד שמה זהירות.
במקרה של ריבוי לקוחות, כלל הגישה וכלל השאילתות הופכות לרגישות, מה שמפזר את הרגישות על פני כמעט כל האפליקציה.מנטור אישי למתכנתים (ולא רק) – להתקדם לשלב הבא!
בכל נושא אפשר ליצור קשר dovid@tchumim.com
-
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?ברור שלא. אבל כל עוד אין לך מענה לשאלה הקריטית של @יוסף-בן-שמעון, איך להיזהר מזה עם שכבה נוספת של הגנה מלבד "זהירות מלטעות", לא יעזור לך שאתה ממש "כמו הגדולים".
אתה לא יודע באמת מה גוגל עושים בהרבה דברים, ולחברות יש בהחלט אתגרים גדולים בעניין. קראתי למשל שלאורקל יש פיצ'ר של מופעים מרובים של אותו מסד, מה שפותר את הבעיה בצורה הכי טובה שיש - אותה סכמה עם נתונים שונים לגמרי ואפשר להקים אין סוף מסדים כאילו הם שורות בטבלה.
-
תמיד הייתה לי מחשבה, בתור אחד שמשתמש ב SQL והID הוא מספר רץ, כשלקוח מכניס תורמים/לקוחות שלו, הID שלו יקפוץ לפי המספור של כלל המשתמשים.
אכן, לא זוכר אם בtrello או ב monday.com כשאני מייצר טבלה חדשה ואחריה עוד טבלה יהיה הבדל בין הid שלהם של X מספרים לאומת ההבדל אם פותחים יום אח"כ או יותר, שהוא הרבה יותר = לענ"ד שהם משתמשים בטבלה אחת, וid רץ לפי הטבלאות של כלל המשתמשים.
אממה לגבי טבלה, שלא אמור לעניין אותך הID זה לא כ"כ מפריע, אבל ברשימת תורמים/לקוחות שאתה רוצה להציג לו את הID זה צורם - אולי באמת אפשר לעשות לבד עוד מספור לפי הרשומות של המשתמש, ובכל פעולה שהמשתמש עושה על תורם/לקוח שלו, צריך לחפש אותו בתורמים/לקוחות בייחד עם הID של המשתמש בעצמו - איך זה נשמע הגיוני ככה לעבוד בכל טבלה, לא קצת מוזר? -
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trelloמדמיין לדוגמא שיתוף בדרייב, (את"ל שזה מאוחסן בכל אחד מהמשתמשים - כל שינוי קטן של שם או קובץ משתנה אצל כולם???)
אם אני רוצה אצלי לעשות תוכנה עם אפשרות שיתוף של לוח מסוים עם משתמשים שונים, ברגע שמדובר בDB ים שונים, העסק נהיה מורכב פי כמה. טעיתי? -
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?אני חושב שזה הדוגמה הכי חזקה למה ש@dovid כתב בהתחלה, גימייל הוא מוצר אחד שגוגל מספקת להרבה משתמשים, אז הגיוני שהכל יישב במסד אחד (ואני לא שולל שבחשבונות עסקיים זה לא משהו נפרד.. באופיס הענן של מיקרוסופט, ניתן לראות במוחש (בצורה שבה מאורגנים הדברים, בעיקר במסוף האדמין) שכל "ארגון" יושב בנפרד, ויש את הארגון הכללי שמיקרסופט מספקת בנפרד), משא"כ בנידון של פותח האשכול, ששם משמע שזה תוכנה שהוא מספק אותה כיחידה לכל לקוח, אבל חלק מהעניין זה שהוא מספק גם את השרתים וכו', ואז אין באמת סיבה לערב בין הדברים...
כעת קראתי שוב את מה שכתבתי למעלה, וראיתי שלא ציינתי שככה עשיתי בפרויקט אחד, אבל בשאר הפרויקטים, עשיתי פשוט מסד נתונים נפרד לכל משתמש/מופע.
לגבי עניין הגיבויים, אז אצלי יחד עם הפונקציות שיוצרות את מסד הנתונים והטבלאות, יש גם פונקציה שמבצעת גיבוי מלא של הdb, וכך כל מופע דואג לגיבוי של עצמו, ואני מנהל את השמירה שלהם בענן בדיוק כמו שהייתי מנהל שמירת גיבויים של db יחיד.
לגבי השידרוגים ושינויים בdb, התרגלתי שלא להריץ שאילתה ידנית, אלא יש לי פונקציה שבה אני מוסיף את השינויים, וככה זה מוגדר בקלות לכל הdb.
-
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
אם אני רוצה אצלי לעשות תוכנה עם אפשרות שיתוף של לוח מסוים עם משתמשים שונים, ברגע שמדובר בDB ים שונים, העסק נהיה מורכב פי כמה. טעיתי?
תלוי בנתונים ובאופי שלהם..
יש לי תוכנה שעובדת עם נתונים של רחובות וערים וכדו', ורציתי שזה יהיה משותף לכלל המשתמשים, אז הפרדתי את הנתונים הללו מהdb הרגיל, ויצרתי db משותף לדברים הללו..
אבל אתה צודק שאם צריך אינטראקציה בין הנתונים הללו לנתונים של המשתמש אז זה עשוי להיות חגיגה, כנראה שבדיוק בשביל זה אומרים שצריך לתכנן את הdb מראש
-
@dovid כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
ההבדל הוא שהמקרה שלך הוא מקרה רגיש מלכתחילה ונקודתי, ממילא קל לבודד ולהיזהר בחוליות הרגישות ולמקד שמה זהירות.
גם המקרה של הרבה לקוחות על מסד אחד כשזה תוכן מלכתחילה הוא מקרה רגיש ונקודתי ולכן בד"כ חושבים עליו כל הזמן, ובד"כ משתדלים שהאובייקט יגיע ממקום אחד ושם תמיד נעשה הפילטור לפני היציאה לDB
אמנם חייבים להיות כל הזמן עם היד על ההדק, אבל בהחלט אני מכיר (ועובד ב) פרוייקטים שזה עובד ככה.
בשאלה הספציפית הזו, בגלל שמלכתחילה הקוד נכתב עבור לקוח בודד הייתי בוחר בDB נפרד כי א"א לדעת איפה בקוד מתחבאות הפתעות שלא חשבנו עליהם.... (כמו שכתבו @yossiz ועוד... )
