How to spot a SQL Antipattern

Survival in the DBA world is following good practises but just as importantly it is about  identifying bad practises. Bad practises can also be called antipatterns. An antipatterns  is a standardised fix to a common problem that may lead to a counterproductive outcome.

There is a well known book – AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis – where this term was first coined. The authors highlighted two criteria required to satisfy a fix as an antipattern

1. A commonly used fix or solution , which may appear to solve the issue , but tends to bad consequences. A simple example may be : SELECT *
2. A credible alternative exists, which if employed, leads to a positive consequence. A simple example , in response to SELECT * is SELECT col1, col2,

There are hundreds of examples in all fields. You may have heard of cart before the horse, scope creep, stovepipe system, blind faith, accidental complexity,busy waiting, hard coding. There are plenty more concepts used which represent this idea of antipattern.

Keeping an eagle eye and having processes in place to identify these SQL Antipatterns, can yield some serious improvements in database server systems and supporting systems management processes.

I’ve started a series called SQL Antipattern. I’ll be posting SQL Antipatterns sightings.

Using NULL as an ordinary value in sql code - SQL Antipattern # 001

The practise of Hard Coding – SQL Antipattern #002

SQL Silver Bullets and Easy Fixes - SQL Antipattern #003

Blind Faith versus Test Oriented programming – SQL Antipattern #004

DRY or WET – SQL Antipattern #005

Performance Tuning by Committee - SQL Antipattern #006

Accidental complexity - SQL Antipattern #007

Premature optimization - SQL Antipattern #008

Query to find non – sargable sql statements – SQL Antipattern #009

T SQL Antipatterns - SQL Antipattern #010