ამ შაბათ-კვირას ჩავუჯექი MongoDB-ს და პირველი დასკვნები რაც გამოვიტანე არის შემდეგი:
1. რელაციური მონაცემები დაფუძნებულია სხვადასხვა ტიპის მონაცემების ურთიერთდამოკიდებულებაზე - მაგალითად კლასი "ადამიანი", რომელსაც გააჩნია უშუალო მახასიათებლები როგორიცაა სქესი, ასაკი, წონა, სიმაღლე, სახელი, გვარი და ა.შ. და ასევე გააჩნია "ირიბი" მახასიათებელი, როგორიცაა საყვარელი ფერი, მუსიკა, პროფესია, განათლება, ოჯახური მდგომარეობა, მეუღლე, შვილები და ა.შ. რელაციურ მოდელში თითოეული ამ მახასიათებლისთვის შეიქმნება ცალკე ცხრილი და ძირითად ცხრილში მოხდება უბრალოდ უნიკალური იდენტიფიკატორით გადაბმა. თუკი ჩვენს მოდელში დაგვჭირდა ისეთი ინდივიდის მონაცემის შენახვა, რომელსაც გააჩნია უნიკალური მახასიათებელი, მაგალითად როგორიცაა "შინაური ცხოველი", რომელიც სხვა ინდივიდებთან არ არის რელევანტური, მაშინ მხოლოდ ამ ერთი ჩანაწერის გამო შესაძლებელია დაგვჭირდეს ცალკე ცხრილის შემნა და ძირითად ცხრილში დამატებით ერთი ველის დამატება. უხეშად რომ ვთქვათ რელაციური მოდელი არის საკმაოდ ხისტი, მაშინ როდესაც არარელაციური მოდელი გვაძლევს სრულ თავისუფლებას მონაცემების სტრუქტურის მხვრივ, ნებისმიერ "ცხრილში" (რომელსაც MongoDB-ში ეწოდება "დოკუმენტი") შეგვიძლია ნებისმიერი მონაცემის შენახვა.
2. თავის მხვრივ დამატებითი თავისუფლება ყოველთვის დამატებითი პასუხისმგებლობის ხარჯზე მოდის. შესაბამისად თუკი რელაციური მოდელის შემთხვევაში მონაცემების ვალიდურობა მთლიანად მონაცემთა ბაზის მართვის სისტემის მხარესაა, არარელაციური მოდელის შემთხვევაში ეს ვალიდაცია მთლიანად ჩვენს კისერზე გადმოდის. აქ არაა საუბარი იმაზე, რომ რიცხვით ველში შემთხვევით ტექსტური მონაცემები არ მოხვდეს, ეს არაფერია იმასთან შედარებით, რომ ჩვენ ასევე უნდა დავრწმუნდეთ თუ რა ტიპის მონაცემს ვწერთ თითოეულ დოკუმენტში, დავრწმუნდეთ რომ სრულად დავამუშავეთ დოკუმენტი და შემდეგ განახლებაზე არ აღმოვაჩინოთ რომ თურმე დოკუმენტის დიდი ნაწილი საერთოდ დაიკარგა, იმის გამო რომ თურმე სადღაც გაპარული შეცდომის გამო განახლებისას ეს ნაწილი არ ჩაიტვირთა კოდის მხარეს და განახლებისას უბრალოდ ამ ნაწილის გარეშე მოხდა დოკუმენტის შენახვა.
3. მასშტაბირება, ეს ალბათ ძირითადი უპირატესობაა არარელაციური მოდელის რელაციურთან. წარმოიდგინეთ რომ საქმე გვაქვს უზარმაზარ მონაცემებთან, რომლებიც ფიზიკურად ვერ ეტევა ერთ სერვერზე და გვჭირდება X რაოდენობის სერვერები ამ მონაცემებთან სამუშაოდ. მონაცემები შედგება Y რაოდენობის ცხრილებისგან, მაგრამ სიმარტივისთვის განვიხილოთ სამ ცხრილიანი მოდელი - A ცხრილში გვაქვს ძირითადი მონაცემები, B და C ცხრილებში დამატებითი მონაცემები, რომლებიც დაკავშირებულია ძირითად ცხრილთან გარე გასაღების მეშვეობით (ძირითად ცხრილში გვაქვს B_ID და C_ID ველები). სამივე ცხრილი მათი სიდიდის გამო გახლეჩილია სამივე სერვერს შორის. პრობლემა გვექმნება მონაცემებთან, რომელთა ძირითადი მხარე იმყოფება ერთ სერვერზე, B დამატებითი მონაცემი მეორეზე, ხოლო C დამატებითი მონაცემი მესამეზე. და ამ შემთხვევაში პირველი, მეორე და მესამე არ განსაზღვრავს სერვერების რიგითობას, არამედ უბრალოდ მიუთითებს იმაზე, რომ სამივე მონაცემი სხვადასხვა სერვერზე დევს. და სრული სურათის მისაღებად მართვის სისტემას იმაზე მეტი ოპერაციის შესრულება უწევს, ვიდრე იმ შემთხვევაში, თუკი ეს მონაცემები ერთ სერვერზე იქნებოდა. და ოპერაციების რაოდენობა სამწუხაროდ ხარისხობრივად იზრდება სერვერების რაოდენობის ზრდასთან ერთად.
ჯერჯერობით სულ ესაა რითიც შემოიფარგლება ჩემი არარელაციური ბაზების ცოდნა. ჩემს მიმდინარე პროექტში მინდა MongoDB-ზე გადავიტანო არსებული სისტემა, ცალკე იმიტომ რომ მინდა უკეთ გავეცნო mongo-ს, და ცალკე იმიტომ რომ mongoDB უფასო ონლაინ 500MB-იან ბაზას სთავაზობს ნებისმიერ მსურველს, რაც დიდი შეღავათია ჩემს შემთხვევაში
ტიპებმა ქვეყნის მომავალი ლომბარდში ჩადეს ფული მოტეხეს და ვალდებულებებს ჩვენ გვიტოვებენ