Voice of the DBA

Author: way0utwest

  • T-SQL Tuesday #109–Influence

    tsqltuesdayThis month’s T-SQL Tuesday host is Jason Brimhall. He asks everyone to write about influence, which is something that I should know about and think I have, but am somewhat uncomfortable writing about.

    That being said, here’s my entry this month.

    Influencing Others

    One of the motivations behind creating SQLServerCentral was to educate and help others. Our goal (Andy, Brian, myself) was to try and find ways that we’d had success, solved problems, or handled challenges and share that with others by writing articles, answering questions, and creating questions for our Question of the Day quiz.

    Across the years as I’ve done that, and I’ve written many editorials, there have been plenty of occasions to meet members of the SQLServerCentral community. Many of them have thanked me or talked about how the site and community made a difference in their careers, which is something I’m quite proud of. Helping others is a form or volunteerism and service, and while this is a vocation for me, it’s also a passion.

    One of the things I think that I’m most proud of us influencing others to also give back and share. I can only do so much, but if I can also convince others to share their knowledge, there is a level of helping and sharing that grows exponentially to everyone in our #SQLFamily. To that end, I have two stories.

    One is about blogging, which I tend to do regularly. I had a friend, someone I met years ago that wanted to start blogging and asked me for some hints and idea. I shared a few things that help me, but also challenged this individual to set a goal for writing. They did, and years later, they have quite a blog. Many of you have heard of this person, but I won’t mention the name here. That’s not important. What is important is they have helped many others and continue to do so today.

    The other story is a person I met at a user group meeting. I was giving a presentation and this individual had some intelligent questions to ask. Over a few meetings, as I talked with this person, I realized they were someone with a lot of talent on the data platform and encouraged them to think about speaking. I did this regularly, and while it took over a year, this person now has spoken at many events, including the PASS Summit.

    It can be scary and intimidating to share knowledge with others publicly, but it is also immensely rewarding and a way of helping others walk the path you have already covered. Perhaps I’ll influence one of you reading today to share some of what you’ve learned with those hungry to learn.

  • SQL Census–From the Redgate Foundry

    The Foundry at Redgate Software is our version of Microsoft Research. Kind of. We tackle some projects that are interesting and might make good products at some point, but we’re looking at the in the investigative phase. You can read about the Foundry here.

    Some interesting work is taking place in the Foundry and there’s one project that I think is interesting and solves a problem that many of us have had, but I’m not sure how commercially viable this is in the real world.

    Maybe you can help us learn more.

    SQL Census

    SQL Census started as investigation into the area of security, something that is both very simple in SQL Server, but can also become a cumbersome, complex, nightmare.

    The work has progressed well, and there’s a product available. Sort of. It’s in the stage where we are trying to decide how to move forward with both future development and starting to sell this. For now, you can get a look at the tool and give us some feedback. We’re really looking for more information about

    • Do you need this for compliance purposes?
    • Will this help you better secure your environment
    • Does this meet permission management needs?
    • Something else?

    We’re like to get more users, especially those that have larger environments where there isn’t a single user or role that everyone has.

    If you’re interested, read a little about the product and give it a try.

  • Republish: Microservices for Databases

    I start my travels to the UK today for SQL in the City. Join me for that on Wednesday, but for today you get Microservices for Databases republished.

  • The Worst Data Breech

    I noticed this week that Australia passed a law that requires companies to hand over user information, even if encrypted. Quite a few articles that point out this might require backdoors to be created in communication systems to comply with the law. Companies are required to provide plain text user communication if they can, or build tools to allow this if they do not have the capability. The proponents of the bill argue this is necessary for criminal prosecution.

    Perhaps they are right, but if this capability is required, this means that either companies will have backdoors built into their products that allow them to decrypt things you might have expected to remain encrypted. That’s disconcerting to me, not because Apple, Google, or someone else might read my communications, but because no company has really proven they can protect all the data they store.

    Can you imagine how many malicious actors might spent their efforts trying to find those backdoor encryption keys? What if there aren’t backdoor keys, but companies decide to build some sort of key logger into software that copies data before it’s encrypted. Can you imagine how problematic it might be to secure that data?

    I’m also concerned because this would mean that there could be a few keys that can be used to get access to encrypted data, something like “master keys” in door locks. In this case, the loss of a key might mean problems for huge numbers of people. The other option would be lots of backdoor keys, potentially a different one for each customer/device, in which case we have a large data set that I’m sure will get leaked. At that time, how likely will it be that we’ll be able to implement new keys for large numbers of people?

    I sympathize with law enforcement. In some ways, their jobs are much harder. In others, however, I think they have many more tools, and the need to weaken encryption doesn’t seem to be necessary. Many of us have a need to secure data, to protect it from unauthorized access. At a time when security is proving to be a challenge and record numbers of data breeches are occurring, do we really want tech companies to start building products with less security? I don’t.

    Steve Jones