Voice of the DBA

Category: Editorial

  • Logging Tables

    I was chatting in one of our DLM webinars and someone asked a question about logging data. I mentioned a few things, but this individual followed up and wanted more information. Specifically, how do you build a logging table?

    It’s an open ended question, but it’s perfect for a poll. How do you construct a table that you use for capturing lots of information that you may or may not query later, but you might only query in a very ad hoc fashion when something has gone wrong. Usually that’s the only time I look through logs, when I’m investigating some type of issue. With that in mind, this week the question is:

    How do you design a logging table?

    I’m looking for two things here: the DDL and the rational for the design. What is good about this design? How does this particular structure (with indexing) allow me to find answers to the questions I might need to ask.

    I realize this is very open ended, but the concept of logging is also open-ended, used different ways for different purposes. If you have problems with logging structures, let us know what design techniques to avoid as well.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Data Masking for Convenience

    I was at Microsoft in Redmond recently and heard an interesting comment from a SQL Server developer. I was debating the data masking feature with a friend, and we were torn on the value of this for various situations we’d each encountered in the past. There are some restrictions, and it doesn’t seem that data masking is really offering a lot of security.

    The Microsoft developer, however, noted that this isn’t really a high security feature. It’s a developer feature. The design of data masking is to prevent that same code from being rewritten over and over by application developers. The use case is really to help with systems that might read some data, like those that print off part of an account number, ID number, credit card number, etc.

    If you read up on the restrictions, this makes sense. If you are just trying to make development more convenient, the feature makes sense. I hadn’t thought about that use case, but the more I consider this, the more I’m sure that data masking does remove a bunch of code that developers might be re-implementing themselves, perhaps with highly variable levels of quality. It also removes the chance that application developers will accidentally pull sensitive data to a client and (poorly) implement mask replacement there.

    I think this feature is being mis-marketed a bit, really to increase sales to executives and management. I’m sure there isn’t anything we can do about that, but I’d love to see technical documents and information about this for developers and DBAs. Give us a more realistic use case and give us better guidance. I think if we got that for many features, there might be more positive responses and great interest from technical professionals to the changes in the SQL Server platform.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Everyone is a Target

    There was a piece in Dark Reading about a security researcher being targeted by a hacking group. While this is more political, this does raise some questions about how hackers might target our systems in the future. It just might be through personalized attacks against anyone that has privileged access.

    In this case, hackers learned who researchers were and made repeated attempts to personally craft phishing attacks against specific people. However since many hackers communicate with each other, and could easily turn from political goals to economic ones, I’d be concerned about how this might affect data professionals in the future.

    We know that social engineering works. While many of our customers and clients do have access to large amount of data and are perhaps easier targets, I would still expect to see attacks against a data professional that manages lots of data. Especially if the individual might have access to high profile data, or multiple companies as a consultant.

    Targeted attacks against individuals could be a concern for many of us. We are usually more conscious of phishing and social engineering, but we’re not invulnerable. Many of us need to practice good security habits, being careful how we access privileged information, and perhaps even finding ways to do so only through containers or virtual machines that may protect us against some of the malware that could slip past us.

    Security is a pain, it’s annoying, it can slow us down, and it is hard to adhere to best practices consistently and constantly. However we need to be careful and vigilant against the regular stream of attacks that will likely continue for the foreseeable future.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Data Sprawl

    When I was starting in the computer industry, it seemed that we had many choices for platforms, but once we had decided on a direction, the companies I worked for standardized on those systems. It seemed that there was less interoperability between vendors, or even subsets of products from those vendors.

    That’s changed and these days I see products from different hardware vendors, different OSes, different development languages, even different database platforms being co-mingled and mixed throughout all sizes of companies. I see developers moving from Windows to OSX to Unix without a blink and data professionals going from SQL Server to MySQL to Hadoop easily.

    Well, maybe not easily. Certainly there are challenges in learning how MySQL operates differently from SQL Server, which is a long way from the import and processing of data in NoSQL systems. However I do see some SQL Server professionals rising to the challenge and learning to work with these disparate technologies.

    It seems to me that many of us in the future will need to develop multiple skill sets with different technologies just to be effective. Many of our companies will continue to deal with more data sprawl as not only will data be stored in RDBMSs and Excel, but we’ll get cloud services, NoSQL systems, and more that contain sets of data our organizations want to combine together.

    We have seen XML and Hadoop integration in the SQL Server platform, with both R and JSON coming in SQL Server 2016. While I don’t know that any of these will come to dominate data analysis, I do think that it will behoove data professionals to be sure they keep their ability to learn sharp by experimenting with new technologies and growing their skills. Your company might not use Hadoop (or any new tech), but if you don’t learn about it, you won’t know if it meets a need you have.

    However, even if you don’t decide to use the technology, the effort spent learning about it will not be wasted. Your brain will be more flexible, and you’ll have less anxiety if you’re asked to take a look at a new technology, maybe graph databases, something that is probably wildly different from anything you’ve ever used.

    Steve Jones

    The Voice of the DBA Podcast

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