תכנון DB

[yossiz]

@WWW המושכל הראשון שלי מסכים למושכל הראשון שלך...
אשמח לשמוע דעות חולקות

[חוקר]

@WWW
השאלה כמה שורות יהיו.
אם מדובר בטבלה שתצטבר מעל מליון שורות לכאורה עדיף לך נפרד לכל מערכת.
אחרת יותר קל לבצע תחזוקה ושינויים, הוספת עמודות וכו' כשזה טבלה אחת עם עמודה של מזהה מערכת.
אציין שאיך שאני עובד עם NODEJS אני טוען מראש את כל הטבלה בעת עליית התהליך, ורק פעולות כתיבה מבוצעות גם מול הד"ב.
ויש לי API שכאשר מבצעים שינויים בממשק שהוא PHP שמבצע ישירות מול הד"ב, במקביל זה מעדכן את התהליך על שינויים שבוצעו, והתהליך משנה את המידע המאוחסן בזיכרון.
זה חוסך המון קריאות מיותרות וגם CPU

[dovid]

לפי הספר טבלה אחת גדולה, כך אני חושב.

[WWW]

@חוקר תודה רבה!

אני ב PHP כך שמה שכתבת בהמשך לא רלוונטי, לגבי השורות זה לא אמור לעבור את ה K200 - 300K.

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

@dovid מה אתה אומר? עדיין כדאי טבלה אחת?

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

[OdedDvir]

@WWW תכנון טוב לא מתחשב רק בזמן ריצה מהיר, אלא גם - ואולי בעיקר - בזמן תחזוקה ויכולת שדרוג.
נכון שמבחינת יעילות אולי תרוויח קצת בחלוקה לטבלאות, אבל לענ"ד זה שייך רק אם המערכות נפרדות לחלוטין ואין שום עניין לבצע שאילתות גלובליות על כל המערכות כאחת.
אם יש כזה עניין, ואפילו לעתים רחוקות - לדעתי אין שאלה.
הגורם המכריע כאן הוא לא הזמן שייקח לבצע שאילתות, אלא בעיקר המורכבות והזמן הרב והיקר של תחזוקת כל המערכות:

1. שם ייחודי לכל טבלה Table1, Table2, ....Table987
   מסתמא תצטרך עוד טבלת עזר כדי לתחזק ולשייך כל טבלה
2. הוספה \ הסרה של שדות מ-1000 טבלאות! (גם אם כרגע נראה לך שלא שייך מפאת השפה)
3. שאילתת איחוד של 1000 טבלאות!

SELECT * FROM Table1
UNION
SELECT * FROM Table2
UNION
SELECT * FROM Table3
UNION
SELECT * FROM Table4
UNION ...........

4. יש עוד כמה תרחישים מסמרי שיער, כמו גיבויים ושחזורים...

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

[WWW]

@OdedDvir תודה רבה!!!
יש לך כושר הסברה נפלא!

@yossiz אתה מסכים?

[yossiz]

@WWW מי אני... אני שומע את הטענות, וזה נשמע הגיוני. בפרט אם יש עצה של "שליפת הנתונים הרלוונטיים למערכת לטבלת עזר" כמו ש@OdedDvir כתב.

[chagold]

בנוגע לעומס, @dovid הפנה כאן לרפליקציה שלפי התיעוד יכולה לסייע גם לנדו"ד. כי תוכל ליצור לכל מערכת טלפונית צאצא נפרד שבו הבקשות יתקבלו ורק הכתיבה תעשה על האב.

[yossiz]

@WWW אמר בתכנון DB:

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

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

[WWW]

@yossiz אמר בתכנון DB:

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

לא הבנתי
אשמח שתסביר לי בדיוק מה לעשות.

[yossiz]

@WWW נגיד שיש לך טבלה כזאת:

CREATE TABLE something (
    "id" uuid NOT NULL,
    "info1" varchar,
    "info2" varchar,
    "info3" varchar,
    "system_id" integer NOT NULL,
     PRIMARY KEY ("id")
);

כאשר system_id זה המזהה של המערכת, אז על כל עמודה שתרצה לסנן לפיו תעשה אינדקס משולב של (system_id, infoX). (ואז נראה לי שאין צורך להשתמש באינדקס ייחודי לעמודת system_id)

[WWW]

@yossiz אמר בתכנון DB:

(ואז נראה לי שאין צורך להשתמש באינדקס ייחודי לעמודת system_id)

אני לא יכול, כי כאמור יש לי ערכים כפולים. דהיינו ייתכנו שתי ID על אותו system_id.
מה שעשיתי כרגע:
PRIMARY KEY על ID ו system_id ביחד.
זה הסינון שאני אצטרך לרוב.
זה טוב?

העניין שלפעמים ארצה לקבל COUNT לפי סינון של system_id בלבד, זה יפריע?

[yossiz]

@WWW אמר בתכנון DB:

PRIMARY KEY על ID ו system_id ביחד.
זה הסינון שאני אצטרך לרוב.
זה טוב?

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

@WWW אמר בתכנון DB:

העניין שלפעמים ארצה לקבל CONT של לפי סינון של system_id בלבד, זה יפריע?

צ"ל COUNT.
זה לא אמור להפריע. תמיד אפשר לסנן לפי איזה מן העמודות השמאליות ביותר של האינדקס שתרצה.