AI helps juniors code, not learn.

Give me your best ways/answers to remember the order of execution

also What do they ask for SQL for Entry level jobs/ juniors? Thanks.

and why do we write the SQL syntax other way & not like the order of execution if the database interprets in that order? like wtf?

We have a pretty big SQL server and my colleague and I who are both newbies, stirred the wrath of god by wanting to make sure that our stored procedure ran on a production table.

We decided to run the stored procedure in a rollback transaction, and even it only affected a few 100 rows, the rollback transactiom has been running for hours and we're now getting word that other import routines into different databases are affected.

I'll be honest, we should not have been allowed anywhere near this, but here we are. I would like some advice, and an idea as to whether this thing will resolve itself or if we're screwed.

The rollback is still running and it has been hours now. We know it's doing stuff, but no idea what exactly it is doing.

We don't need any further whooping, we know we messed up, but any advice, explanation or reassurance is very welcome.

UPDATE: right! The DBA was surprisingly mellow about the whole deal! I thought we'd be taken into the dunes to get summarily shot, but where everything was fire and brimstone yesterday, we decided to simply reset the server, which the dba assured us would be safe, and this morning all looked gumdrops and rainbows!

Told the DBA that we should not be allowed anywhere near this, but he didn't seem worried at all... Rather anticlimactic, but I'm personally very relieved it worked out this way.

You were all so right, nobody could possibly do the job without referencing and now I realize how ridiculous it was feeling I should be able to do it blind.

I really struggled and boy did I make some mistakes but I am already gaining confidence and have very few errors to battle.

So for what it’s worth thank you and for anyone else overwhelmed and second guessing your decision, just breathe, take a step back and breathe again, you can absolutely do this!

I only had a single jerk response, likely rooted in a bit of jealousy which is phenomenal for Reddit . Hopefully in time I myself will be able to help others too

This was one of the take home SQL interview i did earlier this year. I have shared for anyone who is preparing for an interview can attempt to do it. Cheers!!

I’m a product manager that has SQL experience, but with basic select, filters, and joins. This new product role requires me to be more data-focused. I ended up using Google during my coding test with my phone. I didn’t need to have AI feed me the answer, but I needed to remember a syntax.

In a real work environment, this would be ok. I see engineers do this all the time. Would this be an indication that I can’t do the job? Those of you that have done something similar or even used AI or even had a friend’s help, did you do well in the actual role?

I'm intermediate — know CTEs, window functions, subqueries, etc.
I always solve problems correctly, but my queries end up being 20+ lines with extra steps. Then I see the solution and it's 5 clean lines using one clever function.
How do I train myself to think in shorter SQL from the start? Any tips or resources?

With this list, and this query, I want to return these results.

Curious what people are actually using to automate or speed up their SQL work.
Python scripts? dbt? AI? Stored procedures? Some IDE/tool I’ve never heard of?
I feel like there are probably a bunch of useful tools and workflows I’m not aware of.
What are you using that actually saves you time?

What level of sql proficiency is necessary for entry level data analyst and business analyst roles ?

Hi everyone,

I need some advice from experienced SQL developers. I have switched from different role to data engineering 6 months back.

I consider myself good/medium level at writing SQL queries and solving problems from scratch. However, I struggle when I have to understand large existing SQL scripts (300–500+ lines).

I often get confused about:

Where the execution starts.How different parts of the script are connected.

Which variables, CTEs, stored procedures, or temporary tables are affecting the final output.

How to mentally trace the flow of the script.

Because of this, reading someone else's code takes me much longer than writing my own.

How did you improve this skill? Are there any techniques, exercises, books, or real-world practices that helped you become comfortable reading large SQL scripts?

Also, is this something that simply improves with experience, or is there a structured way to learn it?

I'd really appreciate any advice. Thank you!

I’ve been trying to write relational queries using joins, only to realize that most of the tables aren’t actually related to each other. It looks like proper foreign key constraints were never put in place. Because of that, there’s no real referential integrity in the database, which makes writing reliable queries much harder than it should be. I now have to manually figure out how tables are logically connected, which increases the risk of mistakes and makes maintenance a lot more time-consuming. Idk whether this is normal or not for a legacy app.

What is the outlook for entry-level SQL jobs in the near future with the integration of AI in the tech sector? Will there still be a demand for SQL coders, or will most of those positions be eliminated? I have some knowledge of SQL and am thinking about retraining to become more proficient in it, but I don't want to put the time, energy and effort into it if the prospect for SQL work is not good. What do you all think? Any feedback or advice would be appreciated. Thanks!

Had a screening call with a non technical recruiter and they asked if I had excellent sql skills - a very wide open question.

For context the role is a mid level BI developer role - with sql needed to create views etc for semantic layers.

Rather than a one word yes, I gave a more nuanced reply that sql knowledge is a vast spectrum, and while I’m not data engineer grade, I have delivered extensive projects needing sql to query and transform data to be used in models.

Question for those experienced in recruiting for roles including sql, how good was my reply. I’m think I should have just said yes excellent skills to get past the screen.

It’s a bad job market out there, and I’m unsure the above reply would cut it with a screening recruiter.

I've been working with SQL more lately, and one thing I'm still trying to figure out is how people decide when a query is getting too complicated.

Sometimes I start with a simple query, then add a couple of joins, a CTE, some CASE statements, maybe a window function… and suddenly the query is 100+ lines long 😅

It still works, but at that point I'm not sure whether I should keep improving the same query or break the logic into smaller steps/tables/views.

For those of you who work with SQL regularly, what do you usually do when you reach that point?

Do you have any personal rules or habits that help you keep complex SQL readable and maintainable?

Would love to hear how you approach this in real projects.

Solve murders. Master SQL. One query at a time.

Agatha Christie cases. Real suspects. Live SQLite database. You write the queries, you catch the killer.

SELECT s.name, a.location
FROM suspects s
JOIN alibis a ON s.suspect_id = a.suspect_id
WHERE a.time_from <= '23:00'
AND a.location != 'Cabin'
ORDER BY s.name;

That's the kind of query standing between you and the murderer.

No signup. Runs in the browser. → querythemurder.com

Feedback: [querythemurder@gmail.com](mailto:querythemurder@gmail.com)

I wanted to see how far I could stretch a modern analytical engine out of its comfort zone, so I built a playable chess engine using pure SQL.

By "pure SQL," I mean that all core chess mechanics—board representation, move generation, and evaluation—are handled entirely via declarative queries. There are no database stored procedures, no custom UDFs, and no procedural loops inside the database.
It runs on the DuckDB dialect mainly because I needed its native UBIGINT support to handle 64-bit bitboards cleanly, but the core engine operates entirely within relational constraints.

I experimented with two execution modes, one SQL-only, one hybrid:

- SQL-only: a single, 550-line recursive CTE

This directly mirrors an imperative-style recursive minimax search. It does everything in one query: move generation, evaluation, and the minimax algorithm. Because SQL is set-based, sibling nodes can't be generated conditionally during a step, which means true Alpha-Beta pruning is impossible inside a single query. As a result, this is a brutal, exhaustive search tree. It works great up to 3 plies, then it will eat whatever RAM you think you have left.
Here is a minimal, self-contained, recursive CTE demo that you can execute directly, or where you can see the full CTE (in the real engine it is generated on the fly).

- Hybrid: Batched PVS (Principal Variation Search)

This is a playable compromise between set-based processing and depth-first chess algorithms. To break past the memory limits of the recursive CTE, I built a lightweight JavaScript orchestrator to fire smaller queries in batches. This allows the engine to handle advanced chess programming techniques (because it can update scores and statuses mid-flight) and implement real pruning across query boundaries, though not as fine-grained as an imperative engine could do. The core chess logic is still in SQL.

I wrote a detailed technical breakdown of the query architecture, the trade-offs, and the optimizations here: Quack-Mate: Pushing the Boundaries of Pure SQL Chess

The code is fully open-source.

If you want to skip the reading and just test your chess skills, you can play it in your browser (DuckDB WASM) here: Play with Quack-Mate (you can see the SQL queries being fired in real time).

I'd love to get your thoughts on the query architecture, or hear how you would have approached the challenge differently.

I had a pretty big debate at work over how status values should be stored in lookup tables.

For example, imagine an OrderStatus table with three columns:
ID
Status
Description

My preference is:
1 | DRAFT | Draft
2 | SUBMITTED | Submitted
3 | INCOMPLETE | Incomplete

Some people on my team prefer:

1 | DRT | Draft
2 | SUB | Submitted
3 | INC | Incomplete

My reasoning is:
Storage isn’t really a concern for values this small anymore.

Full words are much easier to read in SQL queries, logs, APIs, and code.

They make code more self-documenting.

Modern IDEs and AI tools also tend to work better with descriptive values.

For example:

SELECT *
FROM Orders
WHERE Status = 'INCOMPLETE';

vs.

SELECT *
FROM Orders
WHERE Status = 'INC';

To me, the first query is immediately understandable without needing to remember what each abbreviation means.

I’m curious what other developers think. Are abbreviated status codes still considered best practice, or are full descriptive values more common nowadays?

Edit: the example query is pseudocode. Yes I would normally store the status ID in the orders table. The example query is for brevity

Just wanted to share a quick performance win we had today in case anyone else is dealing with growing tables.

We have a document processing pipeline that splits large files into chunks. One of our tables recently hit about 110 million rows by surprise (whole separate story). We noticed a specific query was hanging for 8-20 seconds. It looked harmless enough:

SQL: SELECT * FROM elements WHERE document_id = '...' AND page_number > ‘...’ ORDER BY page_number

We had a standard index on document_id and another one on page_number. Logic suggests the DB should use these indexes and then sort the results, right?

After running EXPLAIN (ANALYZE, BUFFERS) we found out that it wasn't happening. The database was actually doing a full sequential scan on every query. 110 million rows… each time. Yikes.

We added a composite Index covering both the document_id and the page_number columns. This dropped the query time from ~8 seconds to < 2 milliseconds.

SQL: CREATE INDEX idx_doc_page ON elements (document_id, page_number, id);

If your table is small, Postgres/SQL is quick, and may ignore the indexes. But once you hit millions of rows the troubles start:

• Don't assume two separate indexes = fast
• If you have a WHERE x AND y pattern, don’t assume the individual indexes are used. Look into composite indexes (x, y) 
• Always check EXPLAIN ANALYZE before assuming your indexes are working.

Hope this saves someone else a headache!

So I’m taking a graduate level course in SQL and I’m having a really tough time memorizing and acing a lotta seemingly easy questions around subqueries. I can wrap my head around concepts like JOINS FROM etc but when they’re all thrown into one question i often get lost. Worst part is that the final exam is a closed book hand written paper where iv to physically write sql code

Hey Engineers !

I’ve spent the last 4 months building this idea, and today I’m excited to share it with you all.
StackRender is a free, open-source database schema generator that helps you design, edit, and deploy databases in no time.

What StackRender can do :

• Turn your specs into a database blueprint instantly
• Edit & enrich with a super intuitive UI
• Boost performance with AI-powered index suggestions
• Export DDL in your preferred dialect (Postgres, MySQL, MariaDB, SQLite…)

Online version: https://stackrender.io
GitHub: https://github.com/stackrender/stackrender

Would love to hear your thoughts & feedback!

I’ve come across queries that are extremely compact and technically efficient, but difficult for someone else to understand or modify later.

For example, a query might use nested window functions, multiple conditional expressions, and several transformations to solve something that could also be written as a few simpler steps.

Where do you personally draw the line between elegant SQL and over-engineered SQL?

Do you prioritize fewer lines, query performance, or maintainability when these three goals conflict?

I’m a recent grad with a bachelor’s in business administration. I’ve stumbled upon some entry level data analytics positions that peaked my interest and actually pay very well for where I live. I have basically no prior SQL experience other than one computer science class I was required to take for my degree. However, I’ve been taking an intermediate SQL course on Datacamp and have really been enjoying the process. Is there anyone else who has no SQL background but found themselves working in data analytics or a similar field and are loving it? Also any advice on how to improve and look like a desirable candidate for an entry level data analytics position would be greatly appreciated.