cs online - ralva

What have I learned in this quick tour through SQL: 1. Generating EER documents using a SQL Script via MySQL workbench is extremely slick. It actually beats using a drawing program by A LOT. 2. SQL is very functional, being able to run a query and get a deterministic result is very nice. This compared to writing Javascript and dealing with async operations is great. 3. A SQL view is extremely powerful if you want to work with large sets of data. Being able to "hide" complex queries in simple views seems like it would be extremely useful if you're working at scale and with a team. 4. NULL in SQL is weird. Well not weird, but different from Javascript where null is more of a value. In SQL NULL being a state is definitely something that is odd. 5. SQL executes in a way I don't understand. It's not looping through data, instead it's operating on multiple data sets simultaneously. The nature of this is how its so fast, but it's quite a mind-bending concept to t...

Should it be pronounced SEE-QWILL or ES-SKEW-EL ... who knows? Maybe it's like GIF. Potato Tomato. 1. An SQL view is a virtual table whose contents are defined by a stored query. I think of it as a saved SELECT statement that I can interact with as if it were a real table. It's similar to a table because it has rows and columns, and can be queried SELECT to simplify retrieving complex data. However, it's different because a view doesn't store its own data—it just displaying data from the underlying tables. Which sort of makes sense since views don't have their own primary keys. 2. It's hard to compare SQL to a language like Java. Java has a lot more flexibility in data structures. Also Java works synchronously (well unless you count multi-threading) so it's processing data one at a time versus SQL which is fundamentally different under the hood. That said SQL is a lot more "clear" and I think the nature of queries is a lot more determinant than so...

1. From my perspective, a useful example of joining on something other than keys would be to find events that happen in a period of time or specific date. For example, you might need to find all sales that happened during a holiday. This requires joining a Sales table not on an ID, but on a date range. In English, I'm asking the database to "Show me the sales for every sale whose date falls between a holidays start and end date." In SQL, I would write that as something like: SELECT s.SaleID ON s.SaleDate BETWEEN p.StartDate AND p.EndDate; 2. My opinion of SQL is that it's deceptively simple to start with—but very hard to master. I get lost when thinking about queries that require multiple levels of connections or operations. Something like "Find the average number of black cars per car in each state". Even if you had a giant DMV database it would require multiple subqueries or groupings and end up quite complex.

Excited to be starting this database journey! (Albeit with an accelerated timeline thanks to my wedding) 1. From my perspective, the biggest difference between databases and spreadsheets is control. On a spreadsheet, I can type anything anywhere. A database forces me to follow rules, like setting a column to only accept numbers, to keep the data clean. 2. I believe investing my time to learn a database is important for two main reasons. First, apps need a reliable “single source of truth” for data that are both accurate and secure. Second, I want to master the power of SQL. The ability to ask complex questions and get answers from millions of rows of data almost instantly is key when dealing with production data at scale. 3. In this course, I want to learn how to design a database from the ground up. I have had the experience of working with various databases, but in an abstracted form using REST to get data from there -- but its a totally different world getting to design the database...