Voice of the DBA

Category: Editorial

  • The Data Dewey Decimal System

    As a small child, I learned about the Dewey Decimal System in school. Those were the days when you wanted to look up some information or check a fact, you needed to peruse the dead tree books in a library, with information organized by the Dewey Decimal System in the US. At least, all libraries I used in school adhered to this.

    These days we usually use a computer of some sort for learning, research, or really most any work with data. Often I start with Google to find my way to the source of information, but that’s not something that necessarily works well with finding sets of data. It certainly doesn’t work well within a an organization.

    I saw recently that Microsoft announced the general availability of the Azure Data Catalog, which is designed to provide a catalog of data sets. In essence the Data Catalog is an index of the data sets that might be produced by your organization, with the information about the data filled in by the producer of data. Users that are looking for data can query the catalog instead of asking coworkers, wandering through the enterprise databases, or even relying on their own memory of where data might be located.

    At first this seems silly, after all, don’t people inside of an organization know where data is kept? Don’t they learn the servers, databases, and connection methods? Certainly many do, but as with the pace of change these days, as well as the rapidly growing number of ways to publish data these days, it’s entirely possible that many people aren’t aware of all the data sources available inside of an organization. Even at Redgate Software, with a few hundred employees, it is fairly difficult to keep track of what data exists in which location.

    The functionality of the Data Catalog seems a bit basic, and really almost like an extension of adding extended properties to various tables. Certainly things are centralized here, which is good. There are also ways to add other sources, such as SSRS reports, files, and even other relational sources. I’ll have to experiment a bit and see what’s available, and I might encourage you to do the same. The product relies on crowdsourcing, which can go really well, or really poorly, depending on how cooperative your crowd is.

    In any case, I do like the idea of having a central catalog that individuals can update as they produce data sources for others to consume and change what’s available. If it works well, with good searching and tagging, it might eliminate some of the redundant work often performed to surface data inside of any organization and let employees know how to find the answers to their questions.

    Steve Jones

    The Voice of the DBA Podcast

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

  • How Much Can You Learn?

    One of the things we’ve tried to do at SQLServerCentral is provide a way for SQL Server professionals to continue to learn more about the platform over time. Andy Warren and I have debated how to best do this over the years, and Andy has built a great presentation on Building a Professional Development Plan that I’d encourage you to watch or attend if you can.

    One of the parts of any good plan is finding time to learn. While there are many ways in which to learn, many people seem to want an organized way of working through a particular topic. Books provide one method, while online courses such as those provided by Pluralsight are another.  There are also pre-cons at SQL Saturdays or other conferences, weeklong training classes, and other methods available. Which you choose might depend on how you best learn.

    Any of these methods work, but all require some investment, both time and money. Setting aside the money for a minute, how much can you learn in a year if you use some on-demand method such as books or on-demand video. Is there some limit to what you can absorb and work with in any particular month or year?

    I think there is. Certainly the amount you learn depends on how much you can practice and focus on a topic, as well as how closely the new skill is to your existing capabilities. The further you move away from an area you’re already comfortable with, the slower you may learn, and the greater investment to become competent in a new subject. Given that a month (or year) is a fixed amount of time, and we all have other responsibilities, how much can you actually learn and retain?

    I used to think that a few months would build some competence, but I’m finding that after I learn for a few months, I really need a few months, or at least some time, of not learning, where I can practice and work with new skills I’ve been developing. I find that if I don’t take this time, too much of what I’ve learned becomes hard to remember, and even newer skills are hard to acquire.

    Is it the same for you?

    Steve Jones

    The Voice of the DBA Podcast

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

  • Naming Is Hard

    I ran across Aaron Bertrand’s naming post recently, which I liked overall. Your team needs to agree how things are named, and be consistent, but I agree that some of the rules I’ve seen put down by people aren’t practical. However I also know that naming things becomes hard, especially over time as your systems evolve and the scale grows.

    I’ve run into some strange naming patterns in the last few years that struck me as odd. I grew up in the Hampton Roads area of Virginia, and with a parent selling real estate, I traveled all over the area, often reading a map to navigate. I can rarely remember seeing the same names used over and over, despite the fact this was a relatively populous area.

    However when I came to Colorado, I found things to be different. Either the people in charge of naming weren’t creative, or they were very, very lazy. In some of the developments I entered, I’d find the same name used many times on adjacent streets. You can find Wolfe St, Wolfe Pl, Wolfe Ct, and more all next to each other. While a computer can easily differentiate these sets of characters, this can easily create confusion in humans.

    On a note closer to our livelihood, I have seen some strange databases objects. The tables in a JD Edwards system were coded with a short alpha sequence and then a 4 or 5 digit number. Always fun to remember what “FS3401” means. However I saw one recently that stunned me. I ran across a SQL Server database that was quite large, not in data size but in the number of objects. Apparently a developer or DBA at some point decided it wasn’t worth trying to name tables to match some entity and used GUIDs are names instead. I don’t know about many of you, but comprehending which GUID stores which data might have me resigning from that position relatively quickly.

    We won’t all necessarily agree on how we should best name objects and entities, and that’s fine. However I would implore you to at least consider the humans that will have to work with your database. Use some creativity to build names that are easy to differentiate and pronounce for the future DBAs and developers that need to enhance and query your system.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Track Your Consultants

    If you pay attention to security issues in software, you’ve probably heard about man-in-the-middle attacks. These can occur more frequently than you expect, though inside of a company, it’s more unlikely that you’ll experience one if you have some fairly basic security controls on your network.

    However, if you invite someone inside of your network, such as a consultant of some sort, you should be more vigilent. There’s a great post showing how someone can execute a MITM attack against SQL Server. It’s in depth, showing exactly how packet captures lead to the ability to hijack a session and create a new login.

    If this seems like a lot of work, it is. However once the attack is built, this could easily be run by anyone inside of your network. I could see consultants running this type of attack and storing credentials they’ve created for use many months later. These could be sold later to someone that might use them in a website or other application to gather data from outside of your network.

    Defending against these types of attacks is hard. Certainly not allowing free access for consultants is key, though a quick command line execution of a script might not be something that’s easily noticed. At the very least, sysadmin logins should be monitored, and any changes to this list investigated immediately. However, I’d also say any built in server role changes should be checked and verified as being valid alterations. Even your SQL logins shouldn’t change without administrators being aware.

    Monitoring your systems is a big part of security. You might not prevent many of the attacks, but knowing they’ve taken place allows you to respond and potentially protect sensitive data.

    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.