עבודה נכונה מול מסד נתונים ללקוחות נפרדים
-
@יוסף-בן-שמעון כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
טעות יכולה להיות הרת גורל
בהחלט משהו שלא חשבתי עליו, כלומר טעות לוגית בפיתוח (שזה משהו בלתי נמנע) עלולה לתת גישה של לקוח לאחר.
זה כמעט מוריד לגמרי את האפשרות הזאת מעל הפרק, אני כותב כמעט כי אולי אפשר לעשות איזה שכבת הגנה במסד או ביישום מתווך שיבטיח שכל משתמש עובד רק עם שורות שמתאימות לו, כרגע לא מכיר או לא מצליח לחשוב על דרך כזו. -
@יוסף-בן-שמעון
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?@dovid כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
בכזה מקרה התפיסה היא שהמערכת שייכת לגמרי או במידה רבה ללקוח, וגם אין בעצם לבית התוכנה סיבה לערב לקוחות יחד כי זו לא מערכת אחת לשני לקוחות אלא שני מערכות
וכל שינוי או פיצ'ר שרוצים להוסיף, צריך לעדכן אצל כל אחד באופן פרטני?
מותר לציין: שבעצם אם עושים שינויים לכל לקוח לפי דרישתו, אז גם אם מוסיפים משהו או שידרוג בתצוגה, זה דורש התאמה מיוחדת לכל אחד ואפי' רק העתקה לכל אחד לא יספק, כך באמת כל החברות עובדות? -
@avi-rz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
באמת כל אפליקציה שנותנת שירות אפי' בנסיון חינם, מייצרת מסד חדש ללקוח,
בעצם גוגל על כל תיבת מייל פותחת מסד נתונים, או trello ושאר ירקות גם?ההתרשמות שלי הוא שהרבה (אם לא רוב) ה-SAAS-ים לא עושים DB פר לקוח, אלא DB גלובלי אחד. ככה זה גם ב-SAAS-ים שאני עבדתי עליהם.
אפשר למצוא ברחבי הרשת דיונים על זה. ברור שמבחינת אבטחה יותר טוב לעשות מסד נפרד, אבל לעשות מסד גלובלי זו גם דרך לגיטימית.
לגבי הפחד מזליגה של מידע מלקוח ללקוח, ממה שראיתי בפועל זה לא חשש שצריך לשתק אותך, הפתרון הוא מודעות, ועם מודעות הסיכויים של באג חמור יורדים מאוד
אני מדבר בעיקר על שירותים שתוכננו מראש עבור הרבה לקוחות.
במקרה של השואל שזה נבנה בהתחלה עבור לקוח אחד ועכשיו מצטרף לקוח בודד נוסף אני יותר נוטה לכיוון של DB נפרד -
@yossiz כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
לגבי הפחד מזליגה של מידע מלקוח ללקוח, ממה שראיתי בפועל זה לא חשש שצריך לשתק אותך, הפתרון הוא מודעות, ועם מודעות הסיכויים של באג חמור יורדים מאוד
אני מניח הנחה פשוטה:
- כל מפתח יוצר באגים,
- אחד לכמה באגים מגיע לפרודקשיין בטעות
- הסיכוי של באג להגיע לפרודקשיין לא תלוי בחומרתו בכלל, אלא בכמה הוא בולט וקל לתפיסה בקריאה או בהתנהגות. משפטי SQL יכולים להטעות מאוד כי הרבה פעמים משפט SQL שגוי אפילו באופן חמור יראה תוצאות שנראות בסדר גמור ברוב המקרים.
לפי הנחה זו איני יודע על מה אתה נשען, העובדה שמספיק טעות של שני תווים בערך (הן בSQL עצמו והן בקוד שאמור ליצור אותו) בשביל לעשות את הטעות,
היא לא "חשש" אלא סיכוי גבוה ביותר שזה יקרה, גם בזהירות קיצונית. המציאות היא שגם אני וגם אתה טעינו הרבה פעמים וירדו באגים שלנו לפרוקשיין. -
@dovid
הפחד מזליגת נתונים יכול להיות לך גם כשמדובר בלקוח אחד כאשר נציג פשוט יצליח לקבל נתונים של ניהול,
אתה צודק שזה אכן משהו שצריך לשמור מאוד חזק, אבל לדעתי זה לא סיבה לא להשתמש עם db אחד. -
@ivrtikshoret כתב בעבודה נכונה מול מסד נתונים ללקוחות נפרדים:
הפחד מזליגת נתונים יכול להיות לך גם כשמדובר בלקוח אחד כאשר נציג פשוט יצליח לקבל נתונים של ניהול,
למרות שאפשר להגן על בית מגנבים גם אם יש בו חלון זכוכית, עדיין את כלל הקיר עושים בכל זאת מאבנים.
ההבדל הוא שהמקרה שלך הוא מקרה רגיש מלכתחילה ונקודתי, ממילא קל לבודד ולהיזהר בחוליות הרגישות ולמקד שמה זהירות.
במקרה של ריבוי לקוחות, כלל הגישה וכלל השאילתות הופכות לרגישות, מה שמפזר את הרגישות על פני כמעט כל האפליקציה. -
@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 ועוד... )
