המחבר בחר לתת תרומה לקרן האינטרנט הפתוח/דיבור חופשי כחלק מתוכנית כתיבה לתרומות.
מבוא
אם יש לך הרבה ניסיון עם מסדי נתונים יחסיים, זה יכול להיות קשה לעבור מעבר לעקרונות של המודל היחסי, כמו לחשוב במונחים של טבלאות וקשרים. מסדי נתונים מכוונים למסמכים כמו MongoDB מאפשרים לך לשבור את הקשר והמגבלות של המודל היחסי. עם זאת, הגמישות והחופש שמגיעים עם היכולת לאחסן מסמכים עצמאיים במסד הנתונים יכולים להוביל למכשולים וקשיים אחרים.
מאמר מושגי זה מספק חמישה כללים נפוצים הקשורים לעיצוב סכמתי במסד נתונים מכוונים למסמכים ומדגיש שיקולים שונים שיש לקחת בחשבון בעת מודלים קשרים בין נתונים. הוא גם יעבור על מספר שיטות שאפשר להשתמש בהן למודל קשרים כאלה, כולל הטמעת מסמכים בתוך מערכים ושימוש בהפניות ילד והורה, כמו גם מתי שיטות אלו יהיו הכי מתאימות לשימוש.
הנחיה 1 — אחסון יחד של מה שצריך לגשת אליו יחד
במסד נתונים יחסי רגיל, הנתונים מאוחסנים בטבלאות, וכל טבלה מורכבת מרשימה קבועה של עמודות המייצגות מאפיינים שונים המרכיבים ישות, אובייקט או אירוע. לדוגמה, בטבלה המייצגת סטודנטים באוניברסיטה, ייתכן שתמצא עמודות המחזיקות את שמות הפרטיים, המשפחה, תאריך הלידה ומספר זיהוי ייחודי של כל סטודנט.
בדרך כלל, כל טבלה מייצגת נושא בודד. אם היית רוצה לאחסן מידע על הלימודים הנוכחיים של סטודנט, מלגות או השכלה קודמת, יכול להיות שיהיה הגיוני לשמור נתונים אלה בטבלה נפרדת מזו שמחזיקה את המידע האישי שלהם. לאחר מכן תוכל לחבר בין הטבלאות הללו כדי לציין שיש קשר בין הנתונים בכל אחת מהן, מה שמעיד על כך שהמידע שהן מכילות קשור באופן משמעותי.
למשל, טבלה המתארת את מעמד הסכפ"ט של כל תלמיד עשויה להתייחס לתלמידים לפי מספר תעודת הזהות שלהם, אך היא לא תאחסן ישירות את שמם או כתובתם של התלמידים, ובכך תמנע כפילויות נתונים. במקרה כזה, כדי לאחזר מידע על תלמיד כלשהו עם כל המידע על חשבונות הרשתות החברתיות של התלמיד, השכלה קודמת וסכפ"טים, יהיה צורך בשאילתה שתגיע ליותר מטבלה אחת בכל פעם ואז תרכז את התוצאות מטבלאות שונות לתוך אחת.
שיטה זו של תיאור מערכות יחסים דרך הפניות נקראת מודל נתונים מנורמל.מודל נתונים מנורמל. אחסון נתונים כזה – באמצעות מספר עצמים נפרדים ומצומצמים הקשורים זה לזה – גם יתאפשר במסדי נתונים מונחים-מסמכים. עם זאת, הגמישות של מודל המסמכים והחופש שהוא נותן לאחסון מסמכים מוטבעים ומערכים בתוך מסמך בודד אומרים שאפשר למודל את הנתונים אחרת מאשר במסד נתונים יחסי.
המושג הבסיסי למודלינג נתונים במסד נתונים מונחה-מסמכים הוא "לאחסן יחד מה שיופעל יחד". נחפור עמוק יותר לתוך דוגמה התלמידים, נניח שרוב התלמידים בבית הספר הזה יש יותר מכתובת אימייל אחת. בגלל זה, האוניברסיטה רוצה להיות מסוגלת לאחסן כמה כתובות אימייל עם מידע התקשרות של כל תלמיד.
במקרה כזה, מסמך לדוגמה עשוי להיות במבנה כמו הבא:
שימו לב שמסמך הדוגמה הזה מכיל רשימה מוטבעת של כתובות אימייל.
ייצוג יותר מנושא יחיד בתוך מסמך בודד מאפיין מודל נתונים לא מנורמלי. זה מאפשר ליישומים לאחזר ולתפעל את כל הנתונים הרלוונטיים עבור אובייקט נתון (כאן, תלמיד) בפעם אחת ללא צורך לגשת למספר אובייקטים ואוספים נפרדים. כך גם מוודאים את האטומיות של פעולות על מסמך כזה ללא צורך להשתמש בעסקאות רב-מסמכיות כדי להבטיח את השלמות.
אחסון יחד מה שצריך להיגשם יחד באמצעות מסמכים מקוננים הוא לעתים קרובות הדרך האופטימלית לייצג נתונים במסד נתונים מונחה-מסמך. בקווים המנחים הבאים, תלמד כיצד מערכות יחסים שונות בין אובייקטים, כגון יחסים של אחד-ל-אחד או אחד-ל-רבים, יכולות להיות מודלות בצורה הטובה ביותר במסד נתונים מונחה-מסמך.
קווית מנחה 2 — מידול יחסים אחד-ל-אחד עם מסמכים מקוננים
יחס אחד-ל-אחד מייצג אסוציאציה בין שני אובייקטים נפרדים שבהם אובייקט אחד מחובר בדיוק לאחד מסוג אחר.
מתמשיך עם הדוגמא של הסטודנט מהחלק הקודם, כל סטודנט יש רק כרטיס זהות סטודנטית חוקי בכל נקודת זמן נתונה. כרטיס אחד לעולם לא שייך ליותר מסטודנט אחד, ואף סטודנט לא יכול לחזוק יותר מכרטיס זהות אחד. אם היית מנסה לאחסן את כל המידע הזה בבסיס נתונים רלציונלי, כנראה שזה יהיה הגיוני להכניס את היחסים בין הסטודנטים וכרטיסי הזהות שלהם על ידי שמירת רשומות הסטודנטים ורשומות כרטיסי הזהות בשולחנות נפרדים שמחוברים יחד דרך ערכים יחסי.
שיטה נפוצה לייצוג יחסים כאלה במסד נתונים תיעודי היא על ידי שימוש במסמכים מוטמעים. כדוגמא, המסמך הבא מתאר סטודנט בשם סמיי וכרטיס הזהות שלו:
שימו לב שבמקום ערך יחיד, שדה id_card של המסמך הזה מחזיק מסמך מוטמע שמייצג כרטיס הזהות של הסטודנט, ומתואר על ידי מספר זהות, תאריך ההנפקה של הכרטיס ותאריך תפוגת הכרטיס. הכרטיס הזהות באופן עקרוני נהיה חלק מהמסמך המתאר את הסטודנט סמיי, למרות שהוא אובייקט נפרד בחיים האמיתיים. בדרך כלל, הסכמת המסמך הזה כך שתוכל להשיג את כל המידע הקשור דרך שאלה אחת היא בחירה שקולה.
דברים נעשים פחות ישרוניים אם אתה נתקל ביחסים המחברים אובייקט אחד ש
הנחיה 3 – מודלים של יחסים מסוג "אחד לכמה" עם מסמכים מוטבעים
כאשר אובייקט מסוג אחד קשור למספר אובייקטים מסוג אחר, ניתן לתאר זאת כיחס מסוג "אחד לרבים". תלמיד יכול להיות בעל כמה כתובות אימייל, רכב יכול להכיל מספר רב של חלקים, או הזמנת קניות יכולה להכיל מספר פריטים. כל אחד מהדוגמאות הללו מייצג יחס מסוג "אחד לרבים".
למרות שהדרך הנפוצה ביותר לייצג יחס מסוג "אחד לאחד" במסד נתונים מסוג מסמך היא דרך מסמך מוטבע, ישנן מספר דרכים למודל יחסים מסוג "אחד לרבים" בסכימת מסמכים. כאשר מתחשבים באפשרויות למודל אותם בצורה הטובה ביותר, יש שלושה מאפיינים של היחס הנתון שיש לקחת בחשבון:
- כמותיות: כמותיות היא המדד של מספר האלמנטים הבודדים בקבוצה נתונה. לדוגמה, אם כיתה מכילה 30 תלמידים, ניתן לומר שלכיתה יש כמותיות של 30. ביחס מסוג "אחד לרבים", הכמותיות יכולה להיות שונה בכל מקרה. תלמיד יכול להיות בעל כתובת אימייל אחת או מספר. הוא יכול להיות רשום לכמה שיעורים בלבד או שיש לו לוח זמנים מלא לחלוטין. ביחס מסוג "אחד לרבים", גודל ה"רבים" ישפיע על אופן המודל של הנתונים.
- גישה עצמאית: נתונים קשורים מסוימים נגישים לעתים רחוקות, אם בכלל, בנפרד מהאובייקט הראשי. לדוגמה, ייתכן שלא נפוץ לאחזר כתובת דואר אלקטרוני של סטודנט בודד ללא פרטים אחרים על הסטודנט. מצד שני, קורסים באוניברסיטה עשויים להידרש לגישה ועדכון בודדים, ללא קשר לסטודנט או לסטודנטים שרשומים להשתתפות בהם. האם תגיש נגיש מסמך קשור לבד ישפיע גם כן על אופן המודלת את הנתונים.
- האם הקשר בין הנתונים הוא קשר של אחד-ל-רבים באופן מחייב: שקול את הקורסים שבהם סטודנט מסוים משתתף באוניברסיטה. מנקודת מבט הסטודנט, הוא יכול להשתתף במספר קורסים. במבט ראשון, זה עשוי להיראות כקשר של אחד-ל-רבים. עם זאת, קורסים באוניברסיטה נפוצים לעתים רחוקות משתתפים בהם סטודנט יחיד; לעתים קרובות יותר, מספר סטודנטים ישתתפו באותו שיעור. במקרים כאלה, הקשר הנדון איננו באמת קשר של אחד-ל-רבים, אלא קשר רבים-ל-רבים, ולכן תקח גישה שונה למודלת את הקשר מאשר בקשר אחד-ל-רבים.
דמיין שאתה מחליט כיצד לאחסן כתובות דואר אלקטרוני של סטודנטים. לכל סטודנט יכולות להיות מספר כתובות דואר אלקטרוני, כמו אחת לעבודה, אחת לשימוש אישי ואחת שמסופקת על ידי האוניברסיטה. מסמך המייצג כתובת דואר אלקטרוני בודדת עשוי לקחת את הצורה הבאה:
במונחים של כמותיות, יהיו רק מספר כתובות דוא"ל עבור כל סטודנט, מאחר וזוהי סבירות נמוכה של סטודנט יהיו עשרות – ואף מאות – כתובות דוא"ל. לכן, ניתן לאפיין את הקשר זה כקשר אחד-למעט, שהוא סיבה משכנעת לשים כתובות דוא"ל ישירות בתוך מסמך הסטודנט ולאחסן אותן ביחד. אין סיכון שרשימת כתובות הדוא"ל תגדל ללא הגבלה, מה שיגרום למסמך להיות גדול ולא יעיל לשימוש.
הערה: יש להיות מודעים לכמה מלכודות הקשורות לאחסון נתונים במערכים. לדוגמה, מסמך בודד ב-MongoDB אינו יכול לעבור את הגבול של 16MB. למרות שזה אפשרי ונפוץ לשים מסמכים מרובים בשדות מערך, אם רשימת האובייקטים גדלה באופן לא מוגבל המסמך יכול במהרה להגיע לגבול זה. כמו כן, אחסון כמות גדולה של נתונים בתוך מערכים מוטבעים משפיע באופן משמעותי על ביצועי השאילתא.
הטמעת מסמכים מרובים בשדה מערך יהיה סביר במגוון רחב של מצבים, אך יש להבין שזה גם עשוי שלא להיות תמיד הפתרון הטוב ביותר.
בקשר לגישה עצמאית, כתובות דוא"ל כנראה לא יוגשו בנפרד מהסטודנט. כך שאין סיבה משכנעת לאחסן אותן כמסמכים נפרדים באוסף נפרד. זו עוד סיבה משכנעת לשים אותן בתוך מסמך הסטודנט.
הדבר האחרון שיש לשקול הוא האם היחס הזה הוא באמת יחס ״אחד-לשניים״ ולא יחס ״שניים-לשניים״. כיוון שכתובת דואר אלקטרוני שייכת לאדם אחד, זה הגיוני לתאר את היחס הזה כיחס ״אחד-לשניים״ (או אולי באופן יותר מדויק, יחס ״אחד-למעטפה״) ולא יחס ״שניים-לשניים״.
שלושת ההנחות הללו מרמזות ששילוב כתובות הדואר האלקטרוני השונות של התלמידים בתוך אותם מסמכים שמתארים את התלמידים עצמם יהיה בחירה טובה לאחסון סוג זה של נתונים. מסמך תלמיד לדוגמה עם כתובות דואר אלקטרוני משולבות עשוי להיראות כך:
בעזרת מבנה זה, בכל פעם שתאחסן מסמך של תלמיד תקבל גם את כתובות הדואר האלקטרוני המשולבות באותה פעולת קריאה.
אם אתה מתאר יחס מסוג ״אחד-למעטפה״, שבו המסמכים הקשורים לא צריכים להיגשם בנפרד, שילוב מסמכים ישירות כזה הוא בדרך כלל רצוי, כי זה יכול לפשט את המבנה של הסכמה.
כפי שהוזכר קודם, למרות זאת, שילוב מסמך כזה לא תמיד הוא הפתרון האופטימלי. הסעיף הבא מספק פרטים נוספים על למה זה עשוי להיות המצב בכמה תרחישים, ומתאר כיצד להשתמש בהפניות ילדים כדרך חלופית לייצוג יחסים במסד נתונים של מסמכים.
הנחיה 4 — מודלים של יחסים אחד-למרובה ורבים-לרבים עם הפניות ילד
הטבע של היחס בין סטודנטים לכתובות האימייל שלהם הוביל את הדרך שבה ניתן למדל את היחס הזה במסד נתונים מסוג מסמך. יש כמה הבדלים בין זה לבין היחס בין סטודנטים לקורסים שהם משתתפים בהם, ולכן הדרך שבה תמדל את היחסים בין סטודנטים לקורסים שלהם תהיה שונה גם כן.
מסמך המתאר קורס בודד שסטודנט משתתף בו עשוי לעקוב אחר מבנה כזה:
נניח שהחלטת להשתמש במסמכים מוטבעים לאחסון מידע על כל קורסי הסטודנטים, כמו בדוגמה זו:
זהו מסמך MongoDB תקף לחלוטין ועשוי לשמש את המטרה, אך שקול את שלושת תכונות היחס שלמדת בהנחיה הקודמת.
הראשון הוא קרדינליות. סטודנט יישמר כנראה רק עם כמה כתובות אימייל, אך הוא יכול להשתתף במספר קורסים במהלך לימודיו. לאחר מספר שנים של נוכחות, יכולים להיות עשרות קורסים שהסטודנט השתתף בהם. כמו כן, הם ישתתפו בקורסים אלה יחד עם סטודנטים רבים אחרים שגם הם משתתפים בקבוצת הקורסים שלהם במהלך שנות הנוכחות שלהם.
אם החלטת לשלב כל קורס כמו הדוגמה הקודמת, המסמך של הסטודנט יהפוך מהר לבלתי ניהנין. עם מעלה קרדינליות, הגישה של שמירת מסמך מוטמע נעשית פחות משכנעת.
המחשבה השניה היא גישה עצמאית. בניגוד לכתובות דואר אלקטרוני, זה סביר להניח שיהיו מקרים בהם יהיה צורך להשיג מידע על קורסים של אוניברסיטה בפני עצמם. לדוגמה, נניח שמישהו צריך מידע על הקורסים הזמינים כדי להכין דף מקצועי. בנוסף, קורסים יצטרכו להתעדכן במשך הזמן: המרצה שמלמד את הקורס עשוי לשנות, לוח הזמנים שלו עשוי להשתנות, או שתרכיבי ההכרחים שלו יצטרכו להתעדכן.
אם היית שומר על הקורסים כמסמכים מוטמעים בתוך מסמכי הסטודנטים, השגת רשימת כל הקורסים שנוצרים על-ידי האוניברסיטה תהיה מסובכת. כמו כן, כל פעם שיהיה צורך לעדכן קורס, יהיה עליך לעבור על כל התעודות של הסטודנטים ולעדכן את מידע הקורס בכל מקום. שני אלה הם סיבות טובות לשמור על הקורסים בנפרד ולא לשלב אותם לחלוטין.
הדבר השלישי שצריך לשקול הוא האם היחס בין הסטודנט ובין קורס של אוניברסיטה הוא בעצם אחד-לרבים או רבים-לרבים. במקרה זה, זה האחרון, כי יותר מסטודנט אחד יכול להשתתף בכל קורס. אספקט הקרדינליות ו
מסמכים שמייצגים מועגים בתוך תוך אוסף נפרד יכולים להיות מבנים כמו הדוגמאות הבאות:
אם תהחלטו לאחסן מידע על קורסים באופן זה, תצטרכו למצוא דרך לקשר סטודנטים עם הקורסים בדיוק כדי לדעת אילו סטודנטים מתלויים באילו קורסים. במקרים כמו זה בהם מספר האובייקטים הקשורים אינו יותר מדי גדול, בעיקר ביחסים רבים-לרבים, דרך אחת נפוצה לעשות זאת היא באמצעות מיקומים ילדים.
בעזרת מיקומים ילדים, מסמך הסטודנט יש לו הפיכה לעבר מפתגמים על מפתגמים של הקורסים בהם הסטודנט משתתף, באוסף בנוי בתוך אותו מקטע, כמו בדוגמה זו:
שימו לב שבמקטע הדוגמא הזה, עדיין קיים שדה courses שהוא גם אוסף, אבל במקום להכניס מסמכים קורס מלאים כמו בדוגמה הראשונה, רק המפתגמים שמקושרים למסמכים הקורס באוסף הנפרד מוטלים בתוך המקטע. עכשיו, בזמן שאתה משלך מסמך סטודנט, הקורסים לא יהיו זמינים בהתמדה ויהיה עליך לבדוק אותם בצורה נפרדת. מצד שני, מיד ידוע אילו קורסים צריך להשתמש להשתמש. בנוסף, במקרה בו צריך לעדכן פרטים של קורס, רק המסמך של הקורס עצמו צריך להיעדך. כל ההתקשורות בין סטודנטים לאותם קורסים ישארו חסונים.
הודעה: אין כל
אם אתה משתמש במודל יחסים מסוג "אחד לרבים" כאשר כמות המסמכים הקשורים נמצאת בגבולות הסבירים והמסמכים הקשורים צריכים להיגשם באופן עצמאי, מוטב לאחסן את המסמך הקשור בנפרד ולשלב הפניות לילדים כדי להתחבר אליהם.
עכשיו שלמדת כיצד להשתמש בהפניות לילדים כדי לציין יחסים בין סוגים שונים של נתונים, מדריך זה יפרט מושג הפוך: הפניות להורים.
קווין 5 — מודלים יחסים "אחד לרבים" ללא גבולות עם הפניות להורים
שימוש בהפניות לילדים עובד היטב כאשר יש יותר מדי אובייקטים קשורים כדי לשלב אותם ישירות בתוך המסמך ההורה, אך הכמות עדיין נמצאת בגבולות ידועים. עם זאת, יש מקרים שבהם מספר המסמך המשוייכים עשוי להיות לא מוגבל וימשיך לגדול עם הזמן.
לדוגמה, דמיין שמועבר הסטודנטים של האוניברסיטה יש לוח מודעות שבו כל סטודנט יכול לפרסם כל מה שהוא רוצה, כולל שאלות על קורסים, סיפורי נסיעות, מודעות לעבודה, חומרי לימוד, או רק שיחה חופשית. דוגמה להודעה בדוגמה זו כוללת נושא וגוף הודעה:
אפשר להשתמש בכל אחת משתי הגישות שנדונו קודם — שילוב והפניות לילדים — כדי למודל את היחסים האלה. אם היית מחליט על שילוב, המסמך של הסטודנט עשוי לקבל צורה כזו:
עם זאת, אם תלמיד מיומן בכתיבת הודעות, המסמך שלהם יגדל במהירות ויכול בקלות לחרוג ממגבלת ה-16MB, ולכן הכמותיות של יחס זה מציעה נגד הטמעה. כמו כן, ייתכן שיהיה צורך לגשת להודעות בנפרד מהתלמיד, כפי שיכול להיות המקרה אם דף לוח הודעות מעוצב להציג את ההודעות האחרונות שפורסמו על ידי התלמידים. זה גם מרמז שהטמעה אינה הבחירה הטובה ביותר עבור תרחיש זה.
הערה: כדאי גם לשקול אם הודעות לוח ההודעות נגישות לעתים קרובות בעת אחזור המסמך של התלמיד. אם לא, שימוש בהן כולן בתוך המסמך יגרום לפגיעה בביצועים בעת אחזור וטיפול במסמך זה, אפילו כשרשימת ההודעות לא תשמש לעתים קרובות. גישה לא תכוףה לנתונים קשורים היא לעתים קרובות רמז נוסף שאסור להטמיע מסמכים.
עכשיו שקול להשתמש בהפניות ילדים במקום להטמיע מסמכים מלאים כמו בדוגמה הקודמת. ההודעות הבודדות יאוחסנו באוסף נפרד, והמסמך של התלמיד יכול להכיל את המבנה הבא:
בדוגמה זו, השדה message_board_messages מאחסן כעת את ההפניות הילדות לכל הודעות שנכתבו על ידי סמי. עם זאת, שינוי הגישה פותר רק אחד מהבעיות שהוזכרו קודם בכך שכעת יהיה ניתן לגשת להודעות באופן עצמאי. אך למרות שגודל מסמך התלמיד יגדל יותר לאט באמצעות גישת ההפניות הילדות, אוסף מזהי האובייקטים עשוי גם להפוך ללא נוח בהתחשב בכמות הבלתי מוגבלת של יחס זה. בסופו של דבר, תלמיד יכול לכתוב אלפי הודעות במהלך ארבע השנים של לימודיהם.
בתרחישים כאלה, דרך נפוצה לחיבור עצם אחד לאחר היא דרך הפניות הורים. בניגוד להפניות הילדות שתוארו לעיל, כעת לא מסמך התלמיד מפנה להודעות בודדות, אלא הפניה במסמך ההודעה מצביעה לתלמיד שכתב אותה.
כדי להשתמש בהפניות הורים, תצטרך לשנות את סכימת מסמך ההודעה להכיל הפניה לתלמיד שכתב את ההודעה:
שים לב לשדה החדש posted_by שמכיל את מזהה האובייקט של מסמך התלמיד. כעת, מסמך התלמיד לא יכיל שום מידע על ההודעות שפרסם:
כדי לאחזר את רשימת ההודעות שכתב תלמיד, תשתמש בשאילתה על אוסף ההודעות ותסנן לפי השדה posted_by. שמירתם באוסף נפרד הופכת את גידול רשימת ההודעות לבטוח מבלי להשפיע על מסמכי התלמידים.
הערה: בשימוש בהפניות הורים, יצירת אינדקס על השדה המפנה למסמך ההורה יכולה להגביר באופן משמעותי את ביצועי השאילתה בכל פעם שאתה מסנן לפי מזהה המסמך ההורה.
אם אתה ממדל יחסי "אחד לרבים" שבהם כמות המסמכים הקשורים אינה מוגבלת, ללא קשר אם המסמכים צריכים להיות נגישים בנפרד, מומלץ בדרך כלל לאחסן את המסמכים הקשורים בנפרד ולהשתמש בהפניות הורים כדי לחבר אותם למסמך ההורה.
מסקנה
הודות לגמישות מסדי הנתונים המונים, קביעת הדרך הטובה ביותר למודל יחסים במסדי נתונים מונים היא פחות מדע מחמיר מאשר במסד נתונים יחסי. על ידי קריאת מאמר זה, התרגלת להטמעת מסמכים ושימוש בהפניות ילד והורה לאחסון נתונים קשורים. למדת על שקיפות כמות היחסים והימנעות ממערכים בלתי מוגבלים, כמו גם לקחת בחשבון האם המסמך יגיע בנפרד או בתדירות.
אלו רק כמה הנחיות שיכולות לעזור לך למודל יחסים טיפוסיים ב-MongoDB, אך מודל הסכימה של מסד הנתונים אינו מתאים לכולם. תמיד קח בחשבון את היישום שלך ואיך הוא משתמש ומעדכן את הנתונים בעת עיצוב הסכימה.
כדי ללמוד יותר על עיצוב סכמות ודפוסים נפוצים לאחסון סוגים שונים של נתונים ב-MongoDB, אנו ממליצים לך לבדוק את המסמכים הרשמיים של MongoDB בנושא זה.
Source:
https://www.digitalocean.com/community/tutorials/how-to-design-a-document-schema-in-mongodb