Thank you so much! You are my favorite RU-vid teacher. Your video on normalization saved me in my first SQL class! So glad to see new content. I know these must be incredibly time consuming to make, thank you so much for doing them!
That's very kind! I'm glad the normalization video was of so much help to you. These videos are pretty time-consuming to make, for sure, but I figure once I finish making a video it's there forever, and I can see from the comments that a lot of people are genuinely being helped by them. Which motivates me to continue making them, albeit slowly!
You have great presentation skills! Thank you so much for what you do. I'm doing a database management course that I've been struggling with and you're normalization video really helped!
Thank you so much! I have watched several of your videos now, and they are excellent explanations! I love your animations and your format. I was able to pause the videos, stop and think how I would create the Query, and then continue to see the syntax. This has been so helpful. I hope you continue to make new content. I will be eager to see it!
Just over 5 minutes in and I am understand so much better. I have done joins before, but wasn't really able to picture it so it made more sense to me. Thank you.
I am a total stranger to databases in any professional/formal context, even though I have engaged in what I now (after watching your videos) realize was table normalization a couple of times, e.g. while using Dataview in Obsidian, or Notion. After watching this video in particular, it occurred to me that those massive Excel spreadsheets, which some companies base their entire operations on, seem strikingly similar to SQL-based databases with all the JOINs, WHEREs and whatnot. But anyway, I wanted to thank you for all the excellent videos with clear explanations, helpful examples and great visuals. Really looking forward for the video(s) about the 4th&5th Normal Forms :)
Thank you! I love the explanation in simple examples If I can suggest one topic it would be the one you alluded to in the denormalization video about things we can do for processing layer optimization: sharding, indexes, and statistics
Thanks for the great video (again). I have two suggestions. - recursive sql requests (e.g. for hierarchies as employee->boss(also an employee)->boss… and - a join, where I only get one result from the rigt table matched with a condition like min/max/latest (e.g. a gamer joined to (only) the latest purchase he did). Maybe these are to small topics, but maybe they can find a place inside a bigger one. These are often situations that seem to be easier, than they actually are. Thanks for the good content!
thank you for your explanations, they are really great and very helpful. Hope, that you will have a time for new videos. For me will be interesting to see topics like transactions or indexes, or even about executions plans
Learned a LOT from all your videos!! If you don't mind, how do you make these videos? What video editing software are you using? I find it super cool and simple. Thank you!
thanks a lot for such great explanation, but am just confused a bit on self join , specifically on the ON clause , why not use " ap.Approver_Employee_Number = e.Employee_Number" , why are they not interchangeable?
Glad the video was helpful! Re your question: It's easiest if you imagine that the two copies of the Employee table that we're making use of in this query are literally two different tables. One table is called "ap". "ap" is an approver table: every row within the "ap" table represents an approver. The other table is called "e". Every row within the "e" table represents an employee. Now, to your question 'Why not use "ap.Approver_Employee_Number = e.Employee_Number", the first thing to notice here is that "ap.Approver_Employee_Number" refers to the Approver_Employee_Number on the "ap" table. As mentioned above, every row within the "ap" table represents an approver. So ap.Approver_Employee_Number represents the approver of the approver! That's not what we're interested in. We're not interested in the approver of the approver. What we're actually interested in is the employee's approver (e.Approver_Employee_Number), which is why e.Approver_Employee_Number is what appears in the join.
Inner join questions: why do you query that way? I mean Why do you join and then filter, but not get letter of Hydrogen, then filter it from compound details and then query the data only for rows that you interested in? I mean why you do not use natural for manual search algorithm? Whan downsides of that approach?
An SQL query is just a question that we want the database platform to answer for us. The database platform decides what strategy/algorithms to use internally to come up with the answer - all database platforms have "optimizers" which choose the most efficient strategy/algorithms to use internally to answer a particular query. It's pretty likely that in this case, a query optimizer will use a strategy like what you are suggesting. But just remember: an SQL query doesn't prescribe HOW to answer a question. An SQL query IS the question.
@@decomplexify Oh my God! I just had a revelation thanks to you: query = question. So SQL is actually the a way of how to properly ask questions. How on earth that escaped me...? I have always thought that it was just forging your way to the answer, whereas the system is building that for you, you just ask. Thank you so very much!
in the instruction you were changing the names of tables but not using the "as" is there any special way to do this or just giving the new name at the end of the query?
Decomplexify: we bring simplicity to complex topics Also Decomplexify literally 1 second later: suppose we have a database with chemical compounds and their elements ☠️
More sql topics to be simplified: 1. Subqueries and its types. 2. Common Table Expressions 3. Recursive CTEs 4. Date-Time Manipulation 5. Stored Procedures 6. Windowing Functions Please see if you can also help with above topics.
the last result table is wrong as there is not match for 3 ,4,5 in approver_emp_number so the result should contain only 3 rows where they match please tell i am wrong i am looking at for hour trying to know why
Take each row in the table, look at its Approver Employee Number (call it n), then find a row in the Employee table whose Employee Number is n. That's the matching that this join is doing.
@@YoussefAdelZinIf you did that, the query would still return 6 rows, and the headings in the query output would become misleading because "e" is now the approver and "ap" is now a person who gets days off approved by the approver. So the query wouldn't really make sense any more. But it would return 6 rows.
@@decomplexify I understand but it would not contain 2,3,5 it will contain two 1s and three 6s and btw thank you very much for carrying and answering me
Great video but your deduction logic in the elemt tables is wrong, you start "knowing" that Hidrogen is represented by the leter H, but you can't asume this, you should do the folowing: Look at the element table and check what element symbol represent the hidrogen and the go to compound element detail to check element symbol vs compound id and with that go to the compound table
SELECT c.compund_name, c.compund_id FROM compund c JOIN compund_element_detail ced USING compound_id --Or (ON c.compund_id = ced.compound_id) WHERE ced.element_symbol = 'H'
would this not work? This is what I came up with before the video showed its answer. I guess I don't understand why the 3rd table 'Element' needs to be joined. Trying to get better at thinking through this so any help is appreciated
Actually it's a great video But I have a little comment that regarding data integrity You violated it at 20:18 When you listed the employees table You assigned the first row with an approver employee Which is not exist while inserting the row I hope you got me
Hi Marawan, thanks for your comment. There are many options available for enforcing foreign key constraints. One of them is to enforce the constraints only when everything inside the transaction has completed. So: imagine that the insertion of all those rows occurs in a single transaction, and the constraint checking occurs after all the inserts complete, allowing the transaction to commit.
@@decomplexify i know broo But really i love your channel You always talk about important stuff Can you make a video about CTE And ER modeling I think it will be great
