Category: Editorial

  • Republished: Monitoring for Non Existent Events

    Over in the UK today, so the editorial is being republished: Monitoring for Non Existent Events.

  • Kicking off SQL in the City 2018

    I’m off today. Not taking a break, though perhaps it’s a touch of a break. I’m actually in an airplane, heading to the UK for the first 2018 SQL in the City. We’ll be broadcasting this Wednesday, and you can still register and watch. Let your boss know that you can get some cheap training (it’s free), refresh yourself away from work, and you’ll appreciate the perk as a part of your job. Maybe you’ll even get to watch from the comfort of home.

    Grant and Kathi are already in the UK enjoying SQL Bits, but this year I’ve been trying to do less travel and coaching volleyball more. My team of 14 year olds had a tournament yesterday, so I was blowing whistles and giving (loud) advice in a high school gym. Today I’ve got a laptop on a plane and am making my way a third of the way around the world. I may get to watch a movie, but there will certainly be a little demo practice as well.

    The theme for this SQL in the City broadcast is Data Privacy and Protection. GDPR will start being enforced this spring, and many people around the world with be affected. Those outside the EU might not be sure of the ramifications of the regulation, but I wouldn’t be surprised if similar legislation gets passed in other countries. In any case, the idea of ensuring you can control and protect data, with an eye on designing privacy for users into the system, is a good idea.

    You can read the GDPR text, but that’s what many of us have done and tried to interpret it for you. We have a great piece at SQLServerCentral and our product teams have been working hard to ensure that our products will help you improve your compliance. Lots of other vendors are doing the same thing, either working to change their policies or enhance products. Microsoft has certainly spent a lot of effort getting ready, and I’m sure they’re not along in their efforts.

    We all want better security for our data. Many of us empathize with the customers and clients about whom we collect data and often wish our systems provided better security, controls, and options. Sometimes our management doesn’t agree, but certainly they feel the impact if we suffer a data breach. This Wednesday we’ll be talking about Redgate products specifically, but also including general knowledge and ideas that you might use within your organization.

    Register for the event and watch along on Wednesday. Ask questions and see how you can improve your data privacy. Most of our applications could use a little work on security, and we hope to help educate you on what you can do and how Redgate might be able to help.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Build a Career Radar

    I got started in database work during an internship. I was asked to program some Lotus 1-2-3 spreadsheets to help a department. I was pretty proud of the mess I made, since it helped someone with scheduling. Another person noticed and dragged me over to work on some dBase stuff, eventually moving into Clipper and compiled code, even some basic event driven Windows work. This led to some Visual FoxPro and eventually a real database backing the application. The choices I made in moving from Lotus to Clipper to FoxPro to SQL Server (eventually) defined my career.

    I was reminded of those times in reading about technology radars. I’ve seen a few of these from companies like ThoughtWorks, and we’ve even experimented with them at Redgate. The idea of a radar is it’s a living document that assesses risks and rewards of technology. I didn’t create one explicitly early in my career, but I’ve always been interested in reading and learning about lots of technology, with an eye on trying to decide how useful, popular, and valuable different things would be for my career.

    There’s a nice piece from Neal Ford at Thoughtworks that says you should consider building a technology radar. Certainly if you’re in the business of creating technology you might want an organizational radar, but for your career, you might think about the technologies that are around you.

    I didn’t explicitly build my own radar, but I did evaluate Windows v. Linux, betting on the former since I considered the overwhelming inertia from Windows 3.1 and Windows 95. I evaluated Oracle v. SQL Server, and at times I almost wish I’d have chosen Oracle (for the pay drawn working with a cumbersome set of tools), I’m glad that I went with SQL Server. I’ve enjoyed the product most days. There are other choices along the way, including my decision to sit too long on VB v C#, but I can’t guess 100% right. Even now, as I look at R v Python, both choices that are tangential to my work, I’ve thought for a few years that Python was a better choice. I’m glad it was added to SQL Server and I expect its use to eclipse R in a year or two (or three).

    It’s hard to keep up. It can be overwhelming. Eugene Meidinger compares keeping up with learning to the stages of grief. It’s not a bad analogy, and I find many people someone on that spectrum, trying hard to figure out what and how to learn, not to mention finding the time and money to invest.

    I do think that it is important that most of us keep up with changing technology, at least a little. The world is changing and while some, or even many, of us stick with the same job for a long time, I don’t know anyone these days that expects to never change employers. Having a variety of skills, being able to learn quickly, and most importantly, muddle through projects that you know little about are skills that will help you find your way in an uncertain employment situation.

    Steve Jones

    The Voice of the DBA Podcast

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

  • An AI Loophole

    I’ve been working through some of the GDPR legislation, trying to find ways to explain this more clearly to customers and ensure that our products make sense in light of this law taking effect. Redgate is focused in this area and not only do we need to ensure we are compliant, but we also want to ensure we are building tools that help ensure you are compliant.

    In article 14, there’s this text: “the controller shall provide the data subject with the following information… the existence of automated decision-making, including … meaningful information about the logic involved.” That sounds a little concerning for those of us that work with data. It’s not always easy, but we can explain how a SUM or AVG function works, even with a complex OVER() clause and lots of joins and criteria.

    What do we do with a model running under SQL Server Machine Learning Services? The output from those scripts and models is often created by the model, without any obvious way to determine how the results are determined. The requirement to explain is enshrined in a law, one that many people are concerned about. With all the ways that ML and AI systems can get gamed and perhaps contain biases based on the data used to train the model, I can certainly see no shortage of people asking for explanations of decisions or conclusions.

    Fortunately Article 14 also has this part: “the provision of such information proves impossible or would involve a disproportionate effort …” That seems to give companies an out if they are using current systems about which little is known about the black box of machine learning. Certainly organizations are still charged with protecting the data subjects rights and freedoms, but this seems allow for the use of technologies that we can’t quite understand.

    I doubt this was the intention of the authors, though I do hope that this doesn’t prevent the use of newer tools and technologies. What I’d like to see take place is more research and understanding into how the various algorithms we want to use for ML and AI technologies work, perhaps with some more detailed analysis of the inner workings of the models.

    GDPR is going to be an interesting regulation that may have dramatic impacts on the world of data. I’m both excited and concerned to see how things move forward from here. Hopefully this results in better and more responsible data handling and doesn’t degenerate into a series of long term legal battles.

    Steve Jones

    The Voice of the DBA Podcast

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