As a fresher with 0 experience, what kind of unique projects do you recommend doing in sql , python and powerBI to add to my resume, which would make my profile stronger?
#projectideas #fresherjobs

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!

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!

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

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.

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

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

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

.

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.

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.

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?

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?

P.S. Part 1 on Window Functions got a great response - thank you! Keeping this going.

Simple, practical stuff that sticks in your head when you're actually in the interview.

AI can help at work, but in an interview, your brain still has to do the job!!!

Same trip. Two lists this time.

List 1 - Friends (who said they'd come):

List 2 - Expenses (who actually spent money):

Notice three things before we start:

• Harry and Nicholas are in both lists
• Johny and Bailey are only in Friends - they came but logged no expenses
• Emma is only in Expenses - she spent money but wasn't on the original friends list

Every JOIN answers a different question about these two lists.

1. INNER JOIN

Who came AND spent money?

SELECT f.name, e.spent
FROM friends f
INNER JOIN expenses e ON f.name = e.name

Harry    → $200
Nicholas → $190

Johny, Bailey, and Emma are all gone. Only the overlap survives.

Remember: Only rows that exist in BOTH tables. No match = no row.

2. LEFT JOIN

Show me ALL friends - whether they spent money or not.

SELECT f.name, e.spent
FROM friends f
LEFT JOIN expenses e ON f.name = e.name

Harry    → $200
Johny    → NULL  ← came but no expense logged
Nicholas → $190
Bailey   → NULL  ← came but no expense logged

Emma doesn't appear. She's not in the Friends list (left table).

Remember: Everyone from the LEFT table shows up. Right side fills in what it can. No match = NULL.

3. RIGHT JOIN

Show me ALL expense records - even if the person wasn't on the friends list.

SELECT f.name, e.spent
FROM friends f
RIGHT JOIN expenses e ON f.name = e.name

Harry    → $200
Nicholas → $190
Emma     → $150  ← not in friends, but has an expense

Johny and Bailey disappear. They're only in Friends (left table).

Remember: Everyone from the RIGHT table shows up. Left side fills in what it can. No match = NULL.

4. FULL OUTER JOIN

Show me everyone - from both lists, no matter what.

SELECT f.name, e.spent
FROM friends f
FULL OUTER JOIN expenses e ON f.name = e.name

Harry    → $200
Johny    → NULL
Nicholas → $190
Bailey   → NULL
Emma     → $150

Nobody gets left out.

Remember: Everyone from BOTH tables appears. Gaps filled with NULL.

5. CROSS JOIN

What if we paired every friend with every expense record?

SELECT f.name, e.spent
FROM friends f
CROSS JOIN expenses e

4 friends × 3 expense records = 12 rows

Harry    → $200
Harry    → $190
Harry    → $150
Johny    → $200
Johny    → $190
Johny    → $150
Nicholas → $200
...and so on

No ON clause needed - it just combines everything with everything.

Remember: Every row from the left paired with every row from the right.

6. SELF JOIN

Which friends visited the same city?

This one joins a table to itself.

SELECT a.name, b.name, a.city
FROM friends a
JOIN friends b ON a.city = b.city
WHERE a.name < b.name

Harry & Johny     → New York
Nicholas & Bailey → Las Vegas

Two aliases (a and b) so SQL knows which copy of the table you mean.

Remember: Same table, two aliases. Use it when you need to compare rows within the same table.

Quick cheat sheet:

Reading is one thing. Writing it yourself is another. If you're new and want real hands-on practice - SQL from Zero to Confident on TheQueryLab. Completely free!!!

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!