SQL Server Transaction Log File (LDF) Misconception

A common misconception is that setting the recovery model to simple will cause SQL Server not to use the transaction log file (LDF), preventing it from growing to an abnormal size.

In fact, the simple recovery model will still use the transaction log when performing transactions, however it will reclaims log space to keep space requirements small.

The actual file size will not be reduced by reclaiming space.  Same as performing a transactional backup will not reduce the actual file size.

This is important becase if you have a long running transaction that is performing many insert/update/delete statements, the transaction log file could grow (depending on settings) to a very large size.  Once it has grown, it will stay that size until you shrink the log file.

Open/Closed Principle Violation

Before I post too many SOLID principle posts, let me prefix by saying that I strongly believing that following SOLID principles as guidelines will lead to writing better Object Oriented code.

Back to Open/Close Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

Out of all the SOLID principles, I’ve found this one to causes the most confusion and is the hardest to identify for developers.  When following any of the SOLID principles, they all have a bit of cross over that help you identify when violating one of them.  Violating Open/Close principle usually means you are also violating Single Responsibility.

Here are a few smells/tips to for identifying when you might be violating Open/Closed principle:

  • Conditional Code
  • Multiple unit tests due to multiple execution paths
  • Violation of Single Responsibility
[code lang=”csharp”] // Something smells in here…
public int GetSpeed()
int speed = 0;

if (_type is Bike)
speed = 10;
else if (_type is Car)
speed = 70;
else if (_type is Jet)
speed = 300;

return speed;