CSUMB Week 23 (18 June 2025 - 20 June 2025)

Briefly summarize what you consider to be the three (3) most important things you learned in this course.

-1. Gaining knowledge on the necessary software tools to create, connect, and/or modify databases (e.g. MySQL and MongoDB Compass). I feel that tool/software literacy is very important for personal and career development. 

2. Learning query languages such as SQL and MongoDB's JSON-like syntax. Instead of having a "conceptual" knowledge on SQL and what it does, I now have a good practice and grasp on how to use it. I saved all the homework file so I can still practice it in a "LeetCode" style format for fun.

3. How we were able to connect a database and use SQL with JAVA. I always wondered how SQL were implemented in other programming languages. Now I know and I am now able to implement database and SQL into my JAVA projects should I choose to do so. 

CSUMB Week 22 (11 June 2025 - 17 June 2025)

Compare MongoDB with MySQL. 

What are some similarities? 

I didn't really feel like there were too many similarities other than that they both store data. Actually, the CRUD operations looked similar as well.

What are some differences? 

Biggest difference is that Mongo does not use relational tables. It just stuffs all the data into one file without some sense of organization other than having the "collections" and "documents" hierarchy. That sounds a bit wild to me. MongoDB also doesn't have a complete workbench like what MySQL is (I'm assuming since it wasn't shown in the lecture or directions).

When would you choose one over the other? 

I much prefer the SQL's relational structure of database where tables are used. Mongo tries to store everything as a "document" (which is like each data entity within a collection). I also much prefer the fact that SQL can be practice on a MySQL workbench that pretty much offers a full ecosystem to work in. With MongoDB, the fact that I have to pull out Microsoft notes and a command prompt side by side feels like it is 2010. Maybe I'm missing something here because surely this can't be industry standard right? 

I feel like MongoDB is when you try to tell a teenage boy to clean his room and he goes

"Imma shove everything under the bed and if I run out of space, I'll then shove the rest under the couch. That's horizontal scaling for ya"

CSUMB Week 21 (4 June 2025 - 10 June 2025)

I am actually very satisfied with this week. I was wondering how SQL was directly utilized by a different programming language and how to have it be affected toward a website. The bigger picture of how it all generally works makes sense to me now. This was large part due to my struggle with lab 19. I was stuck on lab 19 for about quite a few hours (over 9 hours!) but it didn't feel frustrating as I actually felt like I was learning quite a bit. 

In particular, I enjoyed integrating SQL into Java and especially with how preparedstatements work. I also now understand the value of integrating "model.addAttribute(String attributeName, Object attributeValue)" and how to properly format and set up the catch(SQLException e) to work in order to avoid the default White Space error page. 

CSUMB Week 20 (28 May 2025 - 3 June 2025)

The web site "Use the Index Luke" has a page on "slow indexes".   https://use-the-index-luke.com/sql/anatomy/slow-indexesLinks to an external site. 

If indexes are supposed to speed up performance of query, what does the author mean by a slow index? 

I think what the author means is that sometimes the process is slow despite using index. 

As directly stated by him:

"An index lookup requires three steps: (1) the tree traversal; (2) following the leaf node chain; (3) fetching the table data. The tree traversal is the only step that has an upper bound for the number of accessed blocks—the index depth. The other two steps might need to access many blocks—they cause a slow index lookup,"

he is saying that the search process using index is actually 3 steps and the last 2 steps can slow down the process, thus resulting in a slow speed despite having used indexes. The slowdown process in step 2 can happen when there are too many matches and the slowdown in step 3 can happen when the data is scattered all over the memory.