Voice of the DBA

Author: way0utwest

  • Ignoring Database Version Control

    I find myself surprised that so many people resist keeping their code in version control. I think this is less people all the time, but I don’t have good percentages because at this point I think a fair number of people embarassed enough to not answer the questions. However, in quick conversations, I still find people that don’t think a VCS is necessary. I can’t conceive of this for application code, but more and more I think this also makes sense for database code.

    I ran across a blog that asks you to find a way to keep your database code in a VCS. While I’m glad that the author provides some ideas on how you might script this yourself in a pinch, I think that’s silly. There are tools to help, whether paid for ones, like SQL Source Control or free utilities. In either case, it makes sense to work with something that has been tested a bit rather than inventing your own. It seems that running scripts is simple and easy. In practice, these tools add value because of their maturity. Some of the mistakes you’ll make with your own software have already been made, and solved, with many of these frameworks and paid for tools. Don’t spend your time maintaining software scripts when you need to be developing other software.

    I also think the author makes the process sound a bit simpler and easier than it is. In practice, moving between schema versions in a database is typically a one way process, and rollback scripts are of dubious benefit. A discussion of this post on Hacker News shows some of the shortcomings in trying to version database schemas and easily move between versions. In practice many database schema changes can be rolled forward and back, and the corner cases that are very difficult for tools to solve, aren’t items that occur too often. Really, it’s table changes that are hard, and having a good process helps here, but these are usually one way changes.

    However, the reason I think version control is important is that database development is often disconnected between the database and application. Changes might occur in the database long before they are used in code, or they may need to be undone in development, perhaps in a destructive way that isn’t possible in production. The history of changes, and understanding of what needs to be changed, is much easier with a record in a VCS.

    These days there are a variety of ways to capture your schema changes and record them. I would encourage you to investigate some method and give it a try. Even building the habit of manually recording changes by all developers will help you to move faster and faster in your development process without worrying about losing track of what’s happening.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Mevio .

  • Impressive Accomplishments

    This editorial was originally published on February 15, 2013. It is being republished as Steve is out of the office.

    Most of us have had an interview or two in our lives. We’ve had to assemble a resume or CV, create cover letters, and practice answering questions in preparation for an interview. In all of these things, we are looking for ways to market our past work and present it in the best light as evidence that we will make a good employee in our next position.

    We each have our own experiences, successes, and failures, but we aren’t bound by what’s happened in our career so far. We have the ability to shape our brand for the future by making changes in the way we approach our career from this day forward. I have a talk and blog on this subject, but I certainly don’t have all the answers. I’m always looking for more ideas and suggestions to help people and wanted to ask for your ideas this week.

    What would impress you most about a job candidate?

    Is there something that you’ve seen or heard about in the past that impressed you? If a candidate had written a book, or created some software, would that make you look upon them favorably? I know that a candidate needs to present themselves well in an interview and be able to write SQL, or manage an instance, but when you are examining dozens of resumes, is there something that stands out?

    Take a moment and tell us what has impressed you in the past, and whether it was an indicator of a good employee or not.

    Steve Jones

  • Practicing Deployments

    This editorial was originally published on Feb 18, 2013. It is being re-run as Steve is out of the office.

    It’s said that amateurs practice until they can get something right. Professionals practice until they don’t get something wrong. That’s the idea, and while professionals make mistakes, they make far fewer than those that don’t approach their craft as a professional task.

    Many of us in the data industry develop software in some way. Whether we write queries in T-SQL or build projects in .NET, we produce code to accomplish some task. I’d like to think that many of us improve our skills over time, preferably by practicing new techniques and learning from our mistakes. I know some people stick with the tried and true methods without gaining skill over time, which not only hurts one’s career, but also doesn’t give an employer a reason to value their work.

    However the deployment of software, which encompasses more than the developer(s), doesn’t improve in many cases. Deployment includes operational people’s skills, scheduling dowtime with clients, possible even the briefing of support personel. However the whole process is often performed poorly. Deployments fail, or require more time than expected. People view them as a pain, and software deployment tends to happen less often than it could, resulting in a large software inventory.

    There’s a great quote from James Moore on how we can deploy software better: “…deployments are hard, but rather than long-winded planning, they need constant practice, testing and refining, and we could only do this by deploying early.” Red Gate Software has learned that deploying more often results in the company gaining skill in deploying software, resulting in more successful software changes in applications.

    The improvement you make in your software can bring tremendous value to your clients, but only if they can use those features in the software. Learning to push those changes out in a repeatable, professional manner is a great way to ensure your clients and customers trust you to deliver new features and enhancements that meet their needs.

    Steve Jones

  • Learning All About Always Encrypted at DevConnections

    Like the alliteration in the title? I almost removed it, but decided it had a nice ring. Maybe that should be the title of my IT/DevConnections (Oct 10-13, 2016) session other than End to End Always Encrypted in SQL Server 2016.

    I loved seeing encryption being natively built into SQL Server 2005 (and beyond), but the addition of Always Encrypted in Azure SQL and SQL Server 2016 really intrigued me. In fact, I think many people were very excited about this feature. In End to End Always Encrypted in SQL Server 2016, I cover the detailed workings and setup of the feature and how it can be included in your applications. There’s a lot to think about with encryption features, and I hope to both inform attendees as well as ensure they have a healthy respect for the limitations.

    I’ve given variations of this talk in 2016 and quite a few people have walked away excited, but also re-thinking the “it just works” message from Microsoft’s marketing people.

    If you’re looking for some training, some inspiration, and are a full-stack developer, or multi-technology IT worker, think about coming out to DevConnections. There are a slew of technologies being covered (VS, ASP.NET, C#7, Azure, PowerShell, AWS, SQL Server, Sharepoint, Exchange, Hyper-V and more).

    Register today, use 500SPKR to save $500, and I’ll see you in Las Vegas this October.