Voice of the DBA

Category: Editorial

  • Data Breach Danger

    Recently a court in the US ruled that there was no imminent danger from a data breach at a Texas hospital. This is good news and bad news for the world, and I’m a little torn about how I feel. On one hand, it’s good for us as data professionals that we aren’t necessarily going to be liable for the immediate effects from lost data. While the losses aren’t always our fault, we certainly could feel pressure from management if companies faced immediately legal or financial penalties.

    However it’s bad news because I think there’s little else that data breaches do than cause harm to those whose information is lost. It can be incredibly hard to link a specific breach to a specific identity theft incident, and I see this as a way of allowing companies to escape liability for their poor security practices.

    In reality, however, I have no solution to propose. As a data professional, I try to keep data safe, but it’s very, very difficult. One small hole in your technical infrastructure or human employees and you can lose a ton of data very, very quickly. I know it’s not lost, but copied, however you have lost control of it.

    We will face more and more security incidents, and as those tasked with protecting data, I’m not sure what we can do, or should do. However, I do think that organizations can’t take all responsibility, nor can they take no responsibility. The balance of how to deal with losses and issues is certainly something I hope we work out.

    Soon.

    Steve Jones

  • Data Breach Danger

    Recently a court in the US ruled that there was no imminent danger from a data breach at a Texas hospital. This is good news and bad news for the world, and I’m a little torn about how I feel. On one hand, it’s good for us as data professionals that we aren’t necessarily going to be liable for the immediate effects from lost data. While the losses aren’t always our fault, we certainly could feel pressure from management if companies faced immediately legal or financial penalties.

    However it’s bad news because I think there’s little else that data breaches do than cause harm to those whose information is lost. It can be incredibly hard to link a specific breach to a specific identity theft incident, and I see this as a way of allowing companies to escape liability for their poor security practices.

    In reality, however, I have no solution to propose. As a data professional, I try to keep data safe, but it’s very, very difficult. One small hole in your technical infrastructure or human employees and you can lose a ton of data very, very quickly. I know it’s not lost, but copied, however you have lost control of it.

    We will face more and more security incidents, and as those tasked with protecting data, I’m not sure what we can do, or should do. However, I do think that organizations can’t take all responsibility, nor can they take no responsibility. The balance of how to deal with losses and issues is certainly something I hope we work out a a society.

    Soon.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Design Investment

    This editorial was originally published on Sept 29, 2010. It is being re-run as Steve is traveling.

    I ran across a bit of a rant from Don Halloran on the lack of design effort being made in many applications and software. He talks about a lack of consistency in databases, confusing column names and datatypes not used correctly. Don laments that “It seems database design doesn’t get much respect, and I really don’t understand why this is.”

    We all probably have some idea of why systems get built like this: the designer is ignorant, or lazy, or maybe doesn’t pay attention because it’s not part of their job. Any reason could fit, but ultimately it comes down to someone taking on a job without making the investment in their own career.

    If I were putting tile in my own bathroom, I accept a few mistakes, and I might cut some corners. I might be happy to accept a little fumbling around while cutting tile. I would not, however, put up with that if I were paying someone. I would expect a more professional job. If I decided to change careers and lay tile for a living, I’d also expect to make an investment in my own skills to learn how to do a professional job.

    I understand that developers are paid to write code, and that they are more interested in manipulating objects, methods and properties and implementing DR or indexing. If you plan on working with SQL Server, it pays to make the investment in learning how to do it properly. If for not other reason than because you should consider if part of your professional responsibility.

     

    Steve Jones

  • No State Based Deployments

    I’ve been studying deployment ideas and technologies for quite some time now, but it’s been a focus for the last year or two as my employer is interested in this area. I’ve been reading books and talking to people, comparing their experiences with my own. I’ve found that deployments for databases are much more complex than those for other software, but essentially there are two approaches that people choose: migrations and state based migrations based deployments.

    Migrations based deployments are based on tracking each change to a database in a separate script and then executing each script, in order, on your production database. This is hard to do, requires discipline, and is what most people find difficult to do. Scripts get quite numerous, ordering is hard, and deployments become scary and largely unsuccessful without a lot of care. The scripts require tweaks and fixes to work efficiently, and you need smart DBAs and developers.

    State based deployments are what many people try to use. They look at the state of production, the state of development, run some tool like SQL Compare, or a process, and determine what changes need to be made to production to get it to match development. There are variations, but this is the basis for how many people try to create a deployment process. It seems easier.

    The problem is that at some point a state based deployment process won’t work. It’s actually impossible for a state based approach to work in all situations. Simple actions, like renames, can’t be handled by examining two states. In order to properly manage changes, and keep your data intact and safe, you need to understand “what” happened during the process, not just the end result.

    In many situations, state based deployments can work, and they can be used successfully, but there is always the possibility that you’ll need to customize your state based approach to include some migrations scripting. Keep that in mind, and make sure that any process or tool you choose has that flexibility. If you understand you need to review and modify scripts at times, you should be successful.

    Steve Jones

    The Voice of the DBA Podcast

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