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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.