In my role I build one off reports for clients.
Recently I had my code peer-reviewed (as we do for all code) and it got the green light.
Great!...
For further actions, you may consider blocking this person and/or reporting abuse
Code should be first and foremost readable. If it is readable then it can be fixed by someone, it can be changed by someone, it can be optimised by someone.
Unless you are working with an extremely resource limited environment, then there is no reason why your code should not be Dev first.
Great post.
I've worked doing SQL for back end operational systems AND data warehousing. SQL is literally the one constant in my 20 years of professional work.
Whoever said that about your code clearly missed the mark. Unless you were doing something horribly inefficient, making it readable and traceable is actual "elegance". Doubly so if you're doing analysis that might have to be demonstrated to someone else, or anything that gets reused down the road (dashboards, data integration, etc.) or has to be repeatable.
Good post and that person has the cowboy mentality that makes me think they have a fiefdom to protect via obscurity. Fail.
I love to read SQL articles from you. More of this please.
That nails one of the problems I have with SQL. It often - not always - puts performance at odds with readability.
Part of it is the need for set-based operations. The logic we want to implement applies to individual records. If the record contains this, do that. But once we transform that intent into set-based queries the original logic is often difficult or impossible to discern.
I know that this is a worst-case scenario and it doesn't always have to be this bad, but I've seen SQL where I know for a certainty that no one in a week would be able to read it and understand what it did or why. The developers often couldn't keep track while they were writing it. It was unmaintainable in the most literal sense because the next developer was 100% certain to give up and rewrite it.
It was compounded by the need to use Azure SQL Data Warehouse which deprived us of whatever tools T-SQL offered to break up code into testable units.
That one scenario led me to write this blog post. The point was that 1,000 lines of untestable and unreadable code will be bug-ridden and unmaintainable. We can say "It's SQL, that's how we write it," but the code won't somehow be nice to it because it's SQL and we had no choice. It will punish us without mercy.
Great first post ... welcome to Dev.to :D