cs online - ralva

Coming from MySQL, the biggest difference with MongoDB is how it stores data. In MySQL, I had to carefully plan out my tables and columns ahead of time, and every row had to follow that exact structure. With MongoDB, it feels like I'm working with flexible JSON documents instead of rigid tables. One document can have different fields than the next one and the same collection, which is a huge change. It seems like you can just start building without having everything perfectly mapped out, which is both cool and a little scary. I imagine it would be easy to build yourself into walls. Even though they feel totally different, I'm seeing some similarities that make sense. Every document in MongoDB gets a unique  _id , which feels just like the primary key I'm used to in MySQL for identifying a specific row. They both also use indexes to speed up searches, so the basic idea of making queries fast is the same. The main challenge is learning how to ask for data. I'm used to wri...

Working on a database schema during the group project has been surprisingly challenging. Turning ideas into a single, correct SQL file that everyone agrees on is tough. If someone changes the casing on a column name (like from  doctor_id  to  doctorID)  you can easily break queries. Sharing a .sql file on Google Drive is far from ideal lol. I really wish there was a better tool for this, something like Google Docs but for database design. It would be amazing if we could all see the ER diagram and the schema at the same time and watch changes happen in real-time. We could leave comments, see a version history, and merge our ideas without invaliding someone's code. It feels like a problem that must have a modern solution, because just passing a text file around seems so clunky and makes it hard to focus on actually learning how to design the database. GitDB pls?

We've learned a lot about indexes. Indexes are like the index at the back of a textbook. If we need to read on a topic like "Video Games", we turn straight to page 150 (listed in the Index) and voila -- done. Fast search for something. In essence -- that's how an index works. But how could it be "slow"? What would cause a slow index. I guess to extend the book metaphor it would be like if the index for "Video Games" said page 150, 200, 231, 240, 250, 400, 656, 800, etc. It would take you a LONG time to flip from Index Page to Information Page to Index Page to Information Page and so on. That back and forth gets slower and slower the more pages you have to go through. That's a slow index. In the case of a DB, sometimes if data is scattered -- you should just do a full table scan! Which is what the article on  https://use-the-index-luke.com/sql/anatomy/slow-indexes  talks through.