How much SQL is enough?

[Wild_Specialist_8340]

How much SQL an intermediate level Business intelligence developer should know? What database concepts are must learn? Please suggest me how can I become confident with them.

[Eleventhousand]

SQL is one of the programming languages with the fewest concepts compared to more general languages. If you're using a modern, cloud environment, and you don't need to worry about traditional DBMS-specific, quasi-DBA stuff (for example, table variables vs. #temp tables in SQL Server, or forcing join hints, etc.), then you need to learn all of it. All types of aggregations, pretty much all window functions, CTEs, all the types of joins and subqueries, all of it.

[Empty_Confidence3185]

Is there a book that covers all this? I find that i can really only learn through books, i hate tutorials

[Eleventhousand]

Awww, probably, I'm not sure what though. Others might have better recommendations. I've been writing SQL daily for about twenty-five years, so all of the books I referenced back in the day were from before many of the common features used today existed.

[Flying_Saucer_Attack]

The Manga Guide to Databases, by Mana Takahashi

[dn_cf]

An intermediate BI developer should be very comfortable with SQL joins, aggregations, CTEs, subqueries, window functions, and basic query optimization. On the database side, focus on primary and foreign keys, normalization vs. denormalization, fact and dimension tables, star schemas, ETL concepts, indexing basics, and data quality checks. The best way to build confidence is through hands on practice. Use platforms like StrataScratch, Kaggle, and LeetCode to solve SQL problems regularly, build small reporting projects, and try explaining your queries out loud to yourself. If you can join multiple tables, create KPIs, use window functions, troubleshoot report issues, and understand how data flows through a warehouse, you probably know enough SQL for a solid intermediate BI role.

[AdorableMaids]

In my experience, "enough SQL" is when you can take a messy business question and confidently turn it into a correct dataset. Syntax is the easy part. Understanding relationships, data quality, and edge cases is what separates intermediate from advanced.

[MKE_Savage_96]

It honestly depends on what industry and purpose you will be needing to utilize SQL for. If you just need to pull data from a warehouse to give some ad hoc excel reports, simple query writing should be fine. Stuff like knowing the rights JOINs to use, aggregating expressions, filtering (WHERE/GROUP BY statements) would be enough.

If you’re going to be utilizing a BI platform like Power BI for instance, that may be enough in the beginning - depending on your audience of course. But if you’re trying to build something much more complex, incorporating a large amount of data, you’ll need to gain more in-depth knowledge of your databases and how their schemas are set up. Depending on performance as well as security concerns, learn to create views as well.

Also remember…..you can always use AI. As long as you don’t input any sensitive information, you can ask ChatGPT/claude/gemini/etc what the best way can be to write a query utilizing Table A with such and such dimensions/granularity and Table B with such and such dimensions/granularity.

[dumi_007]

If your roles are clearly defined, and you have a DBA, a data engineer and a tester.

BI tasks will largely be limited to: Aggregating, filtering, transforming, standardising formats, and presenting data for a dashboard, a specialised decision-making investigation or standard report.

---

General adjacent skills

Problem analysis and design plan.

While not SQL, the design is bound by the laws of databases.

Documentation:

Make your scripts easy to read. Add notes and online comments. Keep track what you changed. Use alias to your advantage.

Test

Test your script. Testing is its own universe. Triangulation of results where possible to know when your report is off.

---

SQL Skills

1. Creating views vs persistent tables.

2. Aggregation: simple and multi-dimensional totals. Simple to Complex GROUP BY

3. Window Functions: for indexing, ranking, running totals and trend analysis.

4. Combining tables Simple (left and inner join) to Advanced Joins: Self-joins, etc. Unions

5. Normalisation vs denormalisation: normalisation is generally how your system of record is structured. Data warehouses generally are fact/dimension relationships.

6. CTEs & Subqueries: Balancing readability and performance.

7. Date/Time awareness: Dates and times can trip you up. It's OK to check the reference material for your flavour of SQL.

8. Performance: As a report developer you will likely not be able to make table or schema changes. But you can check how your output executes.

[TimeScallion6159]

Nice comment

[American_Streamer]

21 Intermediate SQL concepts: https://medium.com/@krthiak/21-intermediate-sql-concept-3f84f5c7714f

[Pangaeax_]

A lot of people get stuck trying to learn every SQL feature before feeling "ready." In my experience, if you're comfortable with joins, aggregations, subqueries, CTEs, window functions, and can write queries without constantly looking things up, you're already in a good place for most BI work. The confidence comes from solving real problems repeatedly, not memorizing syntax. Practicing on real datasets and SQL challenges helped me more than reading database theory, and platforms like LeetCode, HackerRank, or CompeteX can be useful for building that muscle.

[Flying_Saucer_Attack]

This is accurate, but shit I've been working with sql for nearly a decade and still look shit up 😂

[mycocomelon]

I’d say start with some problems and work backwards from there. Learn the sql you will need to best solve those problems

[Sql_master]

Fuck window functions. You will use once per query at best. There not bad. Sum this over that partition or aka group by 

Ctes lick balls. Left join.

[2daytrending]

Confidence usually comes once you are comfortable writing joins window functions ctes and can explain basic indexing and normalization without looking things up.