Voice of the DBA

Category: Blog

  • Off

    I’m off for a few days. Actually, today and most of next week. I completed my achievement, getting all my vacation scheduled, and this one of those days. I also have most of next week off, so I’ll be taking time with family over the Thanksgiving holiday to relax a bit, and likely, work on my latest woodworking project.

    The blog will be a bit hit and miss as I work around time off. Apart from next week, and the week of Christmas, I’ve mostly got some random days each week, 1-2, where I hope to have views like this:

    Photo Nov 18, 12 45 28 PM

  • Encryption in Colorado Springs – Encrypting in the Application?

    Last night was my annual presentation at the Colorado Springs SQL Server User Group. I try to make sure I get down there at least once a year, and it’s been only once a year for the last few years. Far too busy, and I’m sorry for that, but I am glad I get invited to go down.

    I presented The Encryption Primer, and there were a few interesting questions asked. Always good to see people debating and asking questions.

    One interesting one from a developer – If I can perform encryption in the application, why would I do use something like TDE or column level encryption?

    To me, I prefer to do encryption as close to the source as possible. If I can do the encryption in the application front end, I’d do it there. It reduces the chances of having the data accidentally disclosed. I don’t have to worry about having data read across the wire, or in a backup tape, or anywhere else.

    However that takes time and effort. Developers are expensive, and they have to write good, solid, secure code in the application. They also have to write this encryption code in every application that accesses the database (reports, ETL, etc.).

    Something like TDE is much easier to setup and use. Column level encryption, while still coding, is centralized.

    It’s a balance, and one you need to consider carefully and thoroughly. It also helps to debate and discuss the decisions about what you protect, why, and what it costs.

  • Practical Problems with CI

    I agree. Continuous Integration has issues in the real world, at least it probably does in many companies. The more tests you have, the more likely you refactoring or changes will break something. The more things break, the more people will look to leave them alone, deferring the "fix" into the future.

    This defeats the purpose of CI. The whole idea is to keep your software in releasable condition. That way you can push it out if you need to.

    How do you deal with the constant build breaks? The first thing I’d do is see if I mad a mistake and can fix my code. That should be the first reaction.

    The next thing is stop for a moment and see what tests are failing. It’s entirely possible that the tests aren’t valid or aren’t needed. Maintenance of tests is an issue. If this is a test that regularly breaks, I might call a quick meeting and see if we should remove it.

    The last thing is that I’d rollback my code and then go back to work on it. Perhaps there’s another way to solve the issue and not break the build.

    This isn’t magic. It’s also not easy. However if you are keeping up with your CI process and it’s healthy, I believe it will pay off over time with better software.

  • SQL Konference 2015

    My first speaking date of the new year is scheduled. I’ll be at the SQL Server Konference 2015, near Frankfurt, Germany. Red Gate arranged things, and I’m looking forward to heading over and renting a car to drive in Germany.

    And speaking, of course.

    I don’t know the agenda or details, or which session I’m presenting, but it’s exciting.

    Slightly bittersweet as I won’t make SQL Saturday #358 in Albuquerque. I’ve been to the last two, taking a day to ski at Taos, but I can’t make it this year as I’ll be speaking that week in Europe.