this post was submitted on 12 Jun 2023
17 points (100.0% liked)

Programming

13368 readers
2 users here now

All things programming and coding related. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago
MODERATORS
 

For me, it's CTE's. I find it amazing to complete a calculation with clear intermediate steps, and goes a long way towards convincing people to use SQL rather than Excel to perform calculations on large tables of data.

What construct do you like using on a daily basis?

top 12 comments
sorted by: hot top controversial new old
[–] [email protected] 7 points 1 year ago (1 children)

Only thing cooler than CTEs are Recursive CTEs, but I struggle to find use cases where I can sneak one in.

[–] [email protected] 4 points 1 year ago

I believe recursive CTEs are pretty cool for tree traversal. Anytime you've got a table with a foreign key on its own primary key they might come in handy.

[–] [email protected] 4 points 1 year ago

I was skeptical of CTEs for a long time. I just used subqueries when I could in T SQL, and then I got a new job and my new company used Postgres. In the adaptation process I took a new look at CTEs and became a convert - it's just nicer and easier to read the intermediate step than as a subquery

[–] [email protected] 4 points 1 year ago (1 children)

CTEs are so helpful for me. They make complex queries much easier to construct and lets me ‘unit test’ the parts I’m working on.

[–] [email protected] 2 points 1 year ago

Same here, CTEs were a game changer for me when I learned about them

[–] [email protected] 3 points 1 year ago (1 children)

Subqueries in Subqueries in Subqueries

[–] [email protected] 1 points 1 year ago

Those work, but require a lot of careful structuring to get right, and can be a pain to debug. With a CTE, you can just call on the intermediate steps to trace down problems.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

You can create a functional enum view by just assigning enums as the column names and storing a single row of the int (or whatever enum) representation.

Then use that view in a cross join. You can (almost) eliminate magic numbers entirely and makes the code much more human legible.

Example

CREATE VIEW AS enum.OrderType
SELECT 
CAST (1 as 'New'),
CAST (2 as 'Pending'),
CAST (3 as 'Shipped')
GO

-- Assuming a table with OrderId and OrderTypeId

SELECT              o.OrderId 
FROM                dbo.Orders AS o
CROSS JOIN          enum.OrderType AS ot
WHERE               o.OrderTypeId = ot.[Pending]

-- Only returns orders where TypeId = 2
[–] [email protected] 3 points 1 year ago
[–] [email protected] 1 points 1 year ago (1 children)

CTEs can be useful, particularly in PostgreSQL, where there are writable CTEs, but a lot of the time, I prefer using temp tables over CTEs, as they often perform better for larger datasets. I think one of my favorite constructs is window functions. I've found many uses for them, over the years.

[–] [email protected] 1 points 1 year ago

There was one time a good while back where I used window functions to perform edge detection in a dataset. I'll see if I can dig up that query later.

[–] [email protected] 1 points 1 year ago

Yes, CTEs are awesome. Especially when you don't force materialization and the optimizer can work its magic.

I've had a lot of fun with window functions as well.

load more comments
view more: next ›