Voice of the DBA

Category: Editorial

  • Anonymous Research

    Anonymity is important

    It’s no secret that anonomizing data doesn’t always work well. We have heard about this when Netflix released their data for people to build algorithms with. Some people were identified based on the data released being correlated with other data the people had entered on the Internet themselves. I know that there are dangers with sharing too much information on the Internet, but people are going to share and there will only be more services in the future for us to use that require data.

    I ran across a post recently from Microsoft researchers that showed similar issues with other anonymous data sets that contain IP information. A number of logs containing traffic from Bing and Hotmail were analyzed with the intention of identifying particular hosts. Even when the data was anonymized, it was possible to identify hosts with a high degree of accuracy.

    You might not think this is a big deal, but as more data is gathered by companies and used for secondary purposes, like analysis, it becomes more likely to be inappropriately released. Is a log on a server more secure, or a copies of multiple logs on analysts’ laptops? I’d think the former, or at least I’d hope the former. If that’s true, then we should really be anonymizing data on a regular basis once it leaves hardened server machines.

    That means we ought to have better algorithms for preventing any identifying information from being retrieved. I would hope that this is an area where research can help, and one that receives a lot of attention in the near future.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Encryption in Production

    WWII era encryption with the Enigma Machine

    The encryption capabilities of SQL Server have been growing in each new version. We have gone from password protected backups to Transparent Data Encryption (TDE), we have moved form PWDENCRYPT() to symmetric, asymmetric keys, and certificates. There are quite a few options available in the current SQL Server platform. However I don’t often see people writing or talking about their use of security.

    It might be the nature of sensitive data means keeping the use of encryption quiet, but that shouldn’t matter. If you are keeping your keys safe, the algorithms and deployments you use should not matter. This Friday I wanted to ask a question about your use of encryption in real world systems.

    If you have sensitive information (identity/financial/medical) data in a database, have you deployed encryption?

    I would like to know if you’ve actually implemented native or third party encryption and if so, in what percentage of the databases that have sensitive information is encrpytion deployed. Do you strip out data before you store it, perhaps only storing something like the last four digits of a credit card in plain text? How diligent do you think your employer is being with regards to encryption?

    If you work with encryption, are you confident that you can recover your systems in a disaster? That’s one question I’d want to be sure I could answer before I deployed any keys in my database.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • API Changes

    Not the best API documentation

    There’s an interesting set of predictions about the possible new APIs (application programming interfaces) that we may see in the future. It’s a look forward into 2012, and a guess that setting standard ways in which we can build systems will become more important in the future. There were two items that I found of particular interest to the data professional.

    The first was the idea that we might have more data APIs in the future, designed to make the exchange of data easier. The people that work with data imports and exports have probably been hoping for his to become more prevalent, and it has gotten better. However I do think that data is becoming the most important part of the technology world. It isn’t the software, or the platform, or the device, but the data that’s available that is the most valuable part of a technology system.

    It isn’t likely that any company can create and manage all this data themselves, especially in a rapidly evolving world where so much of it changes from day to day. A successful business will need to acquire data from other sources and easily integrate the information into its systems,, and an API will make this process smoother. I expect that standards like OData will become something that we work with more in the future.

    The second interesting part of the article talked about the possibility of us seeing more Enterprise APIs, developed and built by individual customers so that their systems can be more easily integrated with others. That would seem to be counterintuitive, but with so much knowledge and talent available outside your company from others that want to build apps to interact with you, I expect this may catch on, at least for those companies that see a demand from partners and customers. One very valuable effect of building an API? You get more data on how your customers use your API, allowing you to better understand how your company might change to enhance its performance.

    Building an API means setting a standard, one you have to support and maintain for years. It can evolve, but the core elements of it will live for a long time, so it helps to gain experience here. Think about providing APIs as you develop software inside yout company, rather than just assuming you’ll build all the functionality needed.

    Steve Jones

    The Voice of the DBA Podcasts

    We have one version of the podcast back and are working to get the others back soon.

  • Going Solo

    This editorial was originally published on Mar 20, 2007. It is being republished as Steve Jones is on vacation. 

    Are you ready to leave the corporate world and become a consultant? It’s a tempting thought and probably one that everyone in corporate America considers at one time or another. Especially those of us in technology who have skills that can easily be used to help some other company.

    Here are 10 reasons not to go into business for yourself, which is an interesting list. It’s from someone who evangelizes the benefits, joys, and methods of escaping the corporate cubicle. If you’re seriously considering becoming a consultant, starting your own business, or going out in any way on your own, I’d recommend her site as a place to learn some things.

    Coming from someone that helped start this site and has worked for it for 3 years this might sound funny. I don’t really like being in business for myself. I know, I’ve been successful, had a good life, let you all know about large parts of it, but the truth is I didn’t love working for myself. If not for Andy and Brian supporting me, I’m not sure I’d have done it.

    Working for yourself, even when you’re successful, isn’t this easy, amazing job. It’s a hassle and it’s hard to worry about the different parts of a business. I’m a writer and a techie. As much as I pay attention to marketing, sales, and other groups, I don’t want to do their jobs. I have an opinion and am happy to express it, but I don’t want to get more involved than that.

    I’m not really advocating one way or the other that you should or shouldn’t start a business or stay in a cubicle. Rather I want to caution you that it’s not as easy as tuning queries. The marketing, accounting, and collections will be as much as the job as the T-SQL.

    Read about other’s experiences, think hard about it, and consider all the parts of the job that you’ll need to do. There’s always more than you think and remember that just as with a new job in corporate America.

    The grass is not always greener.

    If you want to go into consulting, read this book.