Thank this author by sharing:
By Phil Factor,
I tend to worry when people start to mention ‘policies’ and ‘best-practices’ in regard to the development or administration of databases. These are rules, so why not admit it? In many aspects of life we need rules, but in coding with SQL Server there are snags to taking ‘best practices’ too seriously.
I’ll admit that there are advantages were it possible to confidently apply coding rules easily. I’m particularly interested in ways of spotting potential problems in code as part of the development cycle. It is, for example, great to have some generally-accepted ‘best practice’ rules that can be checked as part of continuous delivery or rapid deployment.
So what are the snags?
Perhaps we can present the results of our knowledge and experience in terms of code smells rather than rules. Some coding habits just need investigation and don’t represent a transgression. After all, a smell can come from an excellent cheese or truffle just as easily as a dead rat. Some SQL Server tasks are difficult to automate, but automation can assist judgement and make the task less tiresome, but it can’t replace it.
I'm trying to query our health care database to find the set of patients who meet certain diagnosis ...
problem in my query
SQL server T-SQL best practice
This month’s TSQL Tuesday party is being hosted by Amit Banerjee (Bl...
T-SQL version query Problem
Best Practices for .NET integration