מבנה נתונים ב-MongoDB
_id הוא שדה חובה שמזהה כל מסמך באופן חד ערכי. יש גם אינדקסים.mongod מפעיל את השרת, ו-mongo פותח client כשהשרת כבר פועל. ב-MySQL הפקודות הן mysqld ו-mysql.פרקי ההרצאה: מבנה נתונים ב-MongoDB
תמלול ההרצאה: מבנה נתונים ב-MongoDB
הטקסט המלא של הדקות הראשונות בהרצאה «מבנה נתונים ב-MongoDB» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בדאטאבס שאיננו רלציוני, לדוגמה שלנו דאטאבס מיסוד דוקיומנטס, מבנה הנתונים שונה לחלוטין. בעוד שבדאטאבס רלציוני אנחנו מדברים על תרשים ERD, שבו אנחנו שומרים את הטבלאות, את הנתונים בתוך טבלאות, בפייקטים, בתוך ישויות, בתוך מה שיהיה לימים במערכת
הפיתוח קלאס, ואנחנו גם שומרים, שימו לב, את הקשרים הרלציוניים ביניהם, מה שבעצם מחבר בין הטבלאות, מה שעוקף לנו את הנכונות שיש בין טבלה לטבלה, את הקשר ואת ההיררכיה אם זה one-to-one, one-to-many או ש-many-to-many אם אנחנו בונים
כאן טבלה מקשרת בין הטבלאות עצמם. זה בעולם הרלציוני. בעולם של ה-Documents DB אנחנו שופכים את כל הנתונים פשוט ל-Documents אחד. יש לנו דוקיומנט שמכיל בעצם אוסף של שמות כביכול של קיז, של ערכים, ולאחר מכן יש את הערך בעצמו.
אז עבור ה-ID הערך כאן בהתאמה 1, 2, 3, 4 עד 8 וכולי. ומהו ה-Name? ומהו ה-Address? ומגוון של נתונים יכולים להיכנס לכאן תחת כל תגית ותגית, תחת כל איבר ואיבר בתוך קובץ ה-JSON.
קובץ ה-JSON גם מאפשר לנו היררכיה של הנתונים עצמם. כלומר ב-interest כפי שניתן כאן בשדה אני לא חייב מיד להכניס ערך אלא אני יכול לפתוח גם בתוכו תת מבנה של אותו json כלומר תת json שמכיל גם הוא איזשהו שם של השדה עצמו ואת הערך שלו איזשהו key והvalue שלו.
כך נראה המבנה של json של documents בדוגמה שלפנינו אנחנו יכולים לראות תיאורים שונים של השמות של העמודות כביכול. First name, ויכול להיכנס כאן מחרוזת, יכול להיכנס מספרים, יכולות להיכנס Geo coordinates, לקבל כאן ערכים של מי צדיקים.
כל אחד מהשדות, הם יכולות להכיל הכל. נוסף לכך, נושא מאוד מעניין, בתוך שדה מסוים אנחנו יכולים להכניס מערך.
שדה ב-JSON תוך DocumentsDB הוא לא שדה אטומי שמכיל נתון אחד בלבד בלתי ניתן לפירוק, ממש לא. הוא יכול להכיל גם סדרה של ערכים.
ואם ההתמחויות של אותו בן אדם הן מספר התמחויות כמו בנקינג, פייננס וטריידר, אז אלו הן מספר התמחויות שונות ואנחנו לא נבנה עליהן עוד טבלה אחרת של פרופשיונל ונקשר אותה לאותה ישות שלפנינו, אלא אנחנו ניצור את
מערך ההתמחויות כאן כשדה. זה שדה שמכיל בתוך סוגריים מרובעות, כך אנחנו נציין את המערך עצמו, מכיל בעצם אוסף של ערכים בתוך אתה עצמו. כנראה לגבי קארס, בן אדם יכול להכיל קארסים שונים ולא ניצור עוד טבלה עבור הקארס ונחבר אותה לתוך הישות שלפנינו אם זה עובד או אם זה לקוח, אלא מאחר ויש לו מספר רכבים אז אנחנו נבנה
כאן מערך ולכן עטפנו את כל האובייקטים שלנו כאן דרך סוגריים מרובעות לציין שמדובר כאן בתוך מערך, כאשר בתוך המערך עצמו אין נתונים אטומים עדיין לא הגענו לרמה של נתונים אטומים אלא יש לנו בעצם תת-מסמך, תת-ג'ייסון,
סאב-דוקימנטס, תת-מסמך, עוד מסמך נוסף שהוא מכיל את השדות במקרה שלנו כאן מודל year וvalue, הוא מכיל עוד שדות נוספים שהם רלוונטיים ונמצאים תחת קארדס.
כדי להגיע אליהם צריך להיכנס לדוקימנטס עצמו של פאוול מילר וללכת לתוך הקארדס שלו ורק לאחר מכן לעשות drill-down בפנים על מנת להיכנס לתוך אותם השדות הספציפיים, שגם הם מופיעים בריבוי מקרים, אנחנו רואים כאן גם רכב אחד וגם כ-Rolls-Royce את הרכב מספר 2. זו הטרמינולוגיה שאיתה אנחנו עובדים בדאטאבסט רלציוני,
יש לנו קשרים בתוך סרבר, אנחנו מתחילים מתוך שרת, ומתוך שרת, בתוך כל שרת יכולים להיות לנו מספר אינסטנסים, אפשר כאן היה ליצור גם אינסטנסים או כשרת להכניס כאן בעצם מספר התקנות, אינסטנס, ובכל אינסטנס אנחנו יכולים ליצור מספר דאטאבסים,
כאשר בכל דאטאבס אנחנו בעצם מייצרים מספר טבלאות, כאשר כל טבלה שייכת בעצם לסכמות שונות ובכל טבלה יש לנו מספר שורות. זו הטרמינולוגיה וזה מבנה היררכיה של אובייקטים שמשמשים אותנו בדאטאבס רלציוני.
join אנחנו עושים על מנת לחבר טבלאות, על מנת למזג אותן לפי עמודה כזו או אחרת. לעומת זאת, בדאטאבס שהוא לא רלציוני, כמו בדאטאבס של מונגו דיבי, אין לנו כבר סכמה, אין לנו טבלאות, ומה שאנחנו קוראים לזה טבלאות זה נקרא כבר Collection, זה נמצא בתוך דאטאבס, ומה שהיה נקרא רשומות
עצמם עכשיו זה כבר נקרא דוקימנטס מסמך כל רשומה בעצם היא דוקימנטס בפני עצמו כשיש לי הרבה מאוד דוקימנטסים שנמצאים תחת קולקשן מסוים כך תחת מה שאנחנו מכרנו טבלה מסוימת כשכל אלו נמצאים תחת דאטאבס כזה או אחר שמוגדר לי דאטאבס מוגדיבי