I was discussing with some software developers the DRY software design principle. It is an acronym for "Don’t repeat yourself". For some developers , it’ s considered one of the basic principles of software programming. But like many principles, DRY can be misunderstood and applied in a way leading to confusion.
DRY or WET may be an SQL Antipattern . Read more on how to spot a SQL Antipattern
The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”The principle was formulated by Andy Hunt and Dave Thomas in The Pragmatic Programmer,
To assist me in understanding DRY principle I’ve broken down the definition into two key components
1) piece of knowledge
2) single representation
Most examples of abusing the DRY principle stem from an over emphasis of one of these components. Don’t confuse literal knowledge with meaning. Understanding the context of the literal value makes a difference in how it is used. The word “cup” may mean different things in different parts of the code. Simply creating a variable and associating this value can easily lead to confusion within understanding the code.Maintaining the code, troubleshooting or bug fixing may become a complicated process, due to misunderstanding the usage of values
The DRY principle violation is known a WET “write everything twice” . Comparing WET and DRY practises leads to a useful perspective on best practises.
- Code reuse – How can a script be written to avoid rewriting the same code for the same purpose repeatedly? Avoid copy and paste of code. There are a number of methods within SQL Server to assist
- Views can offer a way of representing common joins. Read more on Precalculated SQL Views data
- Functions are a method to encapsulate certain code, which can be referenced in the main code body. Applying functions need to be carefully considered as they can lead to sub optimal performance - Functions and WHERE clause and suboptimal query plans
- Automated testing versus manual testing. Although not a coding practise, thinking about testing through the DRY lens can lead to a more efficient practise. Why test something manually , when it is possible to automate manual repeatable tasks?
- Database design and schemas. How relational is your database design ? At what point does the design become overly relational and some normalisation needs to be introduced? Analyse the database design to see if it will lead to normalisation
Read more on SQL Antipatterns