In the real world of business or scientific reporting and analysis, data can prove to be awkward. It can be plain wrong or it can be altogether missing. Sure, we have the NULL to signify unknown, but that doesn't play well with regular business reporting. There are a number of ways of dealing with missing information, and methods of estimating data from existing data has a long and respectable history. Joe Celko gets to grips with a data topic that is often treated with some trepidation.
Some time ago, Phil Factor wrote his booklet 'SQL Code Smells', collecting together a whole range of SQL Coding practices that could be considered to indicate the need for a review of the code. It was published as 119 code smells, even though there were 120 of them at the time. Phil Factor has continued to collect them and the current state of the art is reflected in this article. There are now around 150 of these smells and SQL Code Guard is committed to cover as many as possible of them.
The working life of the DBA can be punctuated by surprises, but they aren't generally nice surprises. This is especially true if the DBA is not checking and monitoring the databases for obvious things such as database corruption, and disk space. However, the really scary surprises are less obvious and provide fewer warning signs. Brent Ozar gives six scary surprises that can be avoided by the shrewd DBA.
SQL was designed to be a third-generation language, expressed in syntax close to real language, because it was designed to be easy for untrained people to use. Even so, there are ways of expressing SQL Queries and data manipulation in ways that make it easier for the database engine to turn into efficient action. and easier for your colleagues to understand. Robert Sheldon homes in on data querying and manipulation and makes suggestions for team standards in SQL Coding.