Voice of the DBA

It's always interesting to me when I give product feedback to engineers at Redgate on their demos. Quite often they've built a feature that uses AdventureWorks or Pagila (PostgreSQL) or some other well known schema to evaluate how their particular thing works with a database. I try to remind them that many databases aren't well modeled and designed with consistent naming. I ran across a Daily WTF article that isn't showcasing databases, but it does show some poor naming in data being stored in a PDF. The developer who had to automate a process had to map these fields to database fields, which also might not be named very clearly. In fact, I think I've seen a few database models that used column names like the field names in the PDF. Read the rest of Poor Names

Recently, I saw a graph about making decisions that showed the impact of both reversibility and consequences. Here is an example of such a graph and how one might approach decisions. If things are easily reversible or have a low consequence, we tend to make a decision and move on. Or we are willing to make a decision. One of the examples of such a decision was choosing what to wear out to dinner. It's easy to change, and (in general) of little consequence. Choosing to send a large amount of money to someone through Venmo (or some other mechanism), can be hard to reverse and have substantial consequences. This made me think of some of the DBA and developer decisions I've made in the past. When we work with databases, the changes we make can have a large impact and be quite consequential to our organization. Downtime, data quality, etc. could all impact revenue, profit, reputation, or even future prospects of survival. That can be a lot of pressure when you are deciding to refactor a data model or adjust a lot of data during a deployment. Read the rest of Acting with Confidence

Years ago I was giving a talk on software development and asked the audience how long it takes to review a PR that has 10 lines changed. Answers were in the minutes to tens of minutes range. I then asked how long it takes to review a PR that has 1,000 lines changed. Some people said hours, but a few people said seconds. I've often taken the latter, pessimistic view. Not because I don't think engineers want to do a good job, but because I know human behavior. Most humans will get bored, lose focus, and end up skimming through a large amount of code. Many (most?) people don't want to spend all that time, after all they have they their own code to write. They'll just approve the PR and assume testing will catch any major issues. Read the rest of Barely Reviewed Code

SQL Server Central has been a great success over the last 25 years. We've helped a lot of people improve their careers with the Microsoft Data Platform, primarily SQL Server, but we've published articles on other aspects of databases, including other platforms. I wrote a bit about the history of the site last month, with a few stories in various pieces. We even got Brian Knight to contribute a piece on what the site meant to him. Over the years, we experimented with trying to get an SSIS Central or a SSRS Central off the ground. However, we struggled to find other people who would have been willing to partner with us to provide content and answer questions. Eventually, we gave up, though I wish today we'd have pushed forward with a PostgreSQL Central site a few years back. Read the rest of AI Database Central