SQL antipatterns

About the book

Bill Karwin's SQL Antipatterns takes the familiar idea of design patterns and turns it toward failure. Instead of presenting ideal schemas, it catalogs recurring approaches that seem reasonable at the time and then create maintenance, correctness or performance trouble. Each entry names the pattern, shows why it attracts developers, and works through the consequences before offering alternatives.

The book spans several layers of database work: modeling tables and relationships, writing queries, and handling application-side concerns such as validation and tree-structured data. Karwin's premise is that many bad decisions come from treating SQL as an afterthought to object-oriented code, or from avoiding joins and constraints out of convenience. The remedies generally push toward letting the database enforce integrity and doing set-based work in queries rather than loops.

Because the material is organized around problems rather than a single project, it works as a reference as much as a linear read. The examples are concrete and tied to recognizable development situations, which keeps the discussion grounded in decisions a team actually faces.

How to read it

Approach the entries as diagnostic tools. Read the description of each antipattern and try to match it against schemas or queries you have seen. The value comes from recognizing the shape of the mistake before you commit to it. The alternatives are usually more than one, so compare them against your workload instead of adopting the first suggestion.

The prose is direct and example-driven, with moderate technical density. Readers comfortable with basic SQL will follow the modeling chapters most easily. The query and application chapters reward familiarity with joins, indexes and transactions. Skipping around by topic is reasonable, though reading the modeling material first gives later chapters more context.

Who it suits

Developers who write SQL regularly but learned it on the job will get the most from this book, particularly those who have inherited a schema and wondered why it hurts. Backend engineers, data analysts and technical leads reviewing database changes can use it to name problems in review discussions. Readers new to SQL should build some query experience first, since the book assumes fluency with the basics.

Reading considerations

The examples reflect the database landscape around 2010, so some vendor-specific advice and tooling references may feel dated against current versions. Treat the alternatives as starting points to test against your own engine and workload rather than settled rules. The antipattern framing can also encourage pattern-spotting for its own sake. Not every unconventional design is a mistake.