עבודה נכונה מול מסד נתונים ללקוחות נפרדים
-
תמיד הייתה לי מחשבה, בתור אחד שמשתמש ב 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 ועוד... )
