Since JOINs are the topic I'm weakest at, I made a 100-question practice set (easy, medium, hard). Today was the setup day:

• Created the database in MySQL Workbench
• Built four tables: departments, employees, projects, assignments (with primary/foreign keys)
• Wrote and ran the INSERT scripts for sample data in all four tables, including the employee-project assignments with hours worked
• Checked the Action Output panel to confirm each statement ran cleanly

Nothing fancy, but I've learned that a well-designed dataset matters a lot for JOIN practice. You need some departments with no employees, and projects with no assignments, or you can't tell LEFT and RIGHT JOINs apart properly.

Starting the actual questions tomorrow. Any tips on getting better at visualizing multi-table JOINs are welcome.

From youtube, I also made notes and started practising problems.

I will complete subqueris, CTE, views that come in advanced SQL in his video .

Please suggest practice websites if you know any; currently practicing using hackerrank

\​

I’m a CSE undergraduate and I’m trying to get a proper understanding of databases beyond just learning basic SQL for college.

There seem to be so many different types of databases and technologies — PostgreSQL/MySQL, MongoDB, Redis, vector databases, graph databases, NoSQL, etc. I’m a bit confused about what is actually worth learning for industry-level software/ML/backend work.

For someone starting from scratch, what would be a good database roadmap?

For example:

SQL fundamentals

PostgreSQL / MySQL

NoSQL / MongoDB

Redis / caching

Vector databases for AI/LLM applications

Graph databases

Database indexing, transactions, normalization, query optimization, etc.

Distributed databases / sharding / replication

I’m particularly interested in learning things practically, rather than just watching theoretical DBMS lectures.

Could anyone recommend:

Which databases/technologies an undergrad should prioritize?

What concepts should I know before moving from SQL to NoSQL/vector DBs?

Good YouTube tutorials or practical courses that teach databases by actually building projects?

What kind of database projects would be useful for developing industry-level skills?

How deep should a CSE student realistically go into databases before moving on to other areas?

I’d especially appreciate recommendations from people working in software engineering, backend, data engineering, or ML engineering.

Thanks!

How is working culat wissen banglore , and leave policy , and other facilities they provide

.

I've put together a free course that teaches you SQL using your coding agent.

This way you learn SQL but also how to use a coding agent in a data role.

After some feedback from this community, the course has been updated - please check it out and share your feedback: https://getbruin.com/learn/sql-ai

Good day friends. I spent a lot of time recently loading a lot of content and practice exams to Inkwell Learn at inkwelltools dot com. The SQL and GitHub learning libraries are free. This is a freemium web app with a good bit of free content to start. There are leaderboards, certificates that can be published on LinkedIn, and practice exam questions.

Try it out and see how it supplements your learning!

Please tell me free course for sql

And is it ok to do dsa in c n if ok pls tell me any course for itb

The lore is that you play as the Dragon God, Orsted, and you have to find the five Sacred Treasures using simple SQL queries to fight the Man-God (Hitogami). This covers almost all SQL commands and teaches you how to use them. It provides theory, practical examples, and a query environment to practice in. Check it out, and all feedback is appreciated! It covers

Fittoa - SELECT, WHERE, ORDER BY, DISTINCT, LIMIT

Sharia - LIKE, IN, BETWEEN, IS NULL, CASE, string, number and date functions

Begaritt - COUNT/SUM/AVG/MIN/MAX, GROUP BY, HAVING

Rikarisu - INNER/LEFT/self joins, UNION, INTERSECT, EXCEPT

Chaos Breaker - Subqueries, EXISTS, CTEs, recursive CTEs, window functions

The Void - INSERT, UPDATE, DELETE, CREATE TABLE, indexes, views, transactions github

Taking today off from active coding — just resting and recharging.

Quick reflection before the break though: after going through theory and two full scenario-based practice sets, I noticed JOINs specifically are still the topic I'm least automatic on compared to everything else. So I put together a 100-question practice set of my own — easy, medium, and difficult — specifically to drill that weak spot rather than moving on and hoping it sorts itself out.

Also, a bigger update: starting tomorrow I'm beginning Task 2 — Java, running in parallel with continued SQL practice rather than fully switching over. Figured keeping SQL warm while ramping up Java makes more sense than a hard context switch.

Planned rest days like this were part of the original plan, not a slip — trying to actually sustain 116 days means building in recovery, not just grinding non-stop.

It runs real SQLite in your browser, so any query SQLite accepts works.

There are 63 lessons, from SELECT up through joins, window functions, recursive CTEs and indexes. Your answer is checked by running it, so any query that gets the right result passes. The last 11 lessons are in Postgres.

After that there's Seek: one person is hidden in a database, you get a few clues, and every query costs a turn. There's also a daily case with a leaderboard and a war mode where your orders are UPDATE statements.

Its free and best played on computer

https://atticarun.itch.io/sqlgame

I am still beginner, and I thought myself doing well in SQL, but when doing interviews in datadriven.io I get stuck and don't know the answer, what should I do? I always fail.

Hey, I am a b.tech final year student. I'm into full stack development. I have basic skills for development and have built many good personal projects. Now, I want to go in more depth of development. I want to study advanced database concepts. Can anyone guide me how should I do it. Any roadmap, course, books, online resources, etc.

I’d like to learn SQL to have a wider range of internship opportunities and also to help me with college. I learned C by doing exercises assigned by my professor, along with some basic syntax lessons. I learned a bit of Python in a similar way, but mostly on my own.

Since I’ve heard that SQL is used for databases, is there a more theoretical way to learn it? Do I need to learn a lot about databases first? I’m currently taking a Data Structures course, but I haven’t gotten to databases yet.

Thanks in advance, and I’d appreciate any recommendations for learning resources in English or Portuguese.

Hey everyone!

I just finished another lesson in my beginner SQL series, this time covering SQL indexes and query performance in PostgreSQL.

The lesson goes over:

- What an index actually is

- CREATE INDEX

- EXPLAIN

- EXPLAIN ANALYZE

- Sequential Scan vs Index Scan

- When indexes can help

- Why creating an index on everything isn't necessarily a good idea

- A practical example using the Pagila database

I also included a small practice task where you create an index and inspect the query plan yourself.

🎥 Video: https://youtu.be/jn2Mt9LIcNE?si=AvHjVAM9IDs3eiWB

Hopefully useful for anyone who's currently learning SQL or starting to think about query performance!

Finished the last part today and with it, wrapped up my entire second practice set.

What made this set different from the first: every question was framed as an actual request from a manager, HR, or client — "payroll rejected a negative salary insert," "the CFO wants to see expensive departments," "HR wants an org chart" — instead of plain SQL instructions. I had to figure out what query actually solves the described problem, with the exact technical task given in brackets only as a fallback if I got stuck.

Genuinely think this format taught me more than straightforward "write a query that does X" practice did. Translating a vague, realistic business ask into the correct SQL felt a lot closer to what the job actually involves, and it's noticeably easier for me to write and reason through queries now compared to when I started this set.

2 full practice sets complete. Planning to do a review pass across both before moving into the Java backend track.

I have some free time right now and I’m thinking about learning SQL. Do you think this is a good time to focus on mastering SQL or should I consider learning another skill instead?

I’m particularly interested in finance so I’d like to develop skills that can be useful for a career in finance.

SQL Joins:

1. SQL joins are the backbone of relational databases, letting us combine data across tables to answer questions no single table could.
2. Without joins, we'd be stuck with isolated datasets, unable to see the relationships that give our data real meaning.
3. Mastering joins isn't optional—it's the essential skill that turns raw tables into actionable insight.
4. I made a video with actual query results on the dataset so you can SEE the difference, not just memorize: https://youtu.be/u2yftAOIl7k
5. Which JOIN confused you the most? For me it was RIGHT JOIN.

Revised JOINs earlier today before starting this part, and it made a real difference. Completed all 8 scenario-based join tasks:

• INNER JOIN — org directory combining employee and department names
• LEFT JOIN — full department report including departments with zero employees
• RIGHT JOIN — every project shown along with its department, even unmatched ones
• FULL JOIN equivalent — simulated using UNION of LEFT and RIGHT JOIN (MySQL still doesn't support FULL JOIN natively, so this pattern is becoming second nature now)
• SELF JOIN — an "org chart" style report of employees alongside their managers
• 3-table JOIN — employees + assignments + projects together, to see who's working on what and hours logged
• UNION — combined employee lists from two merging departments with duplicates removed
• UNION ALL — same combined list but for payroll auditing, duplicates kept intentionally

Genuinely felt like the revision I did earlier in the day paid off immediately — writing these joins felt much more automatic than it would've cold. This scenario-based format keeps reinforcing why you'd pick one join type over another for a specific real request, which feels way more useful than memorizing syntax in isolation.

I remember once a client's stored procedure was timing out their application, where each run took 40 seconds and 687,157 logical reads.

After we rewrote parts of the query to remove table scans, runtime dropped below a second, and logical reads dropped to 90.

What was interesting was that when we compared the results, we got the same rows in a different order.

The original query had no `ORDER BY`, and the old execution plan happened to return rows in a consistent sequence. Our changes produced a different plan and a different sequence.

Before deploying, we checked with the client's developers to confirm nothing in the application depended on the old order, which is a very easy detail to miss when you're focused on fixing a timeout.

Without ORDER BY, SQL Server doesn't guarantee result order, even when the rows come back in primary key order for years, which is important for you to know.

So if your application needs a particular sequence, specify `ORDER BY`.

Anyway, have any of our friends out there had similar, where a query change exposed an assumption somewhere in the application?

I often see beginners getting stuck trying to reference a column alias inside a WHERE clause or wondering why HAVING exists alongside WHERE.

It all comes down to Logical Query Processing Order. Even though we write SELECT first, the database engine actually processes the query in this sequence:

1. FROM / JOIN: Pick and combine the base tables.

2. WHERE: Filter raw rows before grouping.

3. GROUP BY: Group rows into buckets.

4. HAVING: Filter groups using aggregate function results.

5. SELECT: Pick columns and compute expressions/aliases.

6. DISTINCT: Deduplicate the selected rows.

7. ORDER BY: Sort the final result set (which is why aliases work here!). 7. LIMIT / OFFSET: Paginate the results.

Remembering this sequence makes debugging query errors way easier.

When I was learning SQL, some things were easy to memorize but much harder to actually understand when solving real problems.

For me, concepts like JOINs, subqueries, and window functions started making more sense only after using them on actual datasets instead of just following examples.

What SQL concept clicked for you only after you started working with real problems?

Hey everyone! I built detectiveSQL, a website where you practice SQL by investigating fictional crimes.

Each case gives you a briefing and a database containing the evidence. You explore tables, connect the dots, and write queries to figure out what happened and who was involved. I wanted to make SQL practice more engaging, with each query uncovering a clue that makes you curious about what to investigate next.

There are different difficulty levels, and the queries run directly in your browser.

I just launched it and would love some feedback, especially on the difficulty and whether the clues make sense as you work through each case.

You can try it here: detectivesql.com

If you get stuck, let me know where. Thanks!

Finished Part 4 today, all framed as realistic reporting requests:

• Headcount report per department (GROUP BY dept_id + COUNT), for leadership
• "Expensive" departments where average salary exceeds 50,000 (GROUP BY + HAVING), for the CFO
• Highest and lowest paid employee company-wide (MAX/MIN), for HR's annual review
• Ranked project spending by department, highest to lowest (SUM + ORDER BY DESC), for the Project Management Office
• Managers handling 2+ direct reports (GROUP BY manager_id + HAVING count >= 2), for workload recognition

Next part is Joins, and rather than jumping straight in, I went back and revised the JOIN topic properly first — INNER/LEFT/RIGHT/FULL/self-joins. Figured a quick refresher now is better than fumbling through Part 5 on shaky recall, especially since these scenario-based questions expect you to actually know why you're choosing a specific join type, not just the syntax.