Voice of the DBA

Category: Editorial

  • Acknowledging Success

    Today is the Redgate annual award event, and I’m honored to be hosting again. I’ve been asked a few times, and I used to look forward to the gathering in Cambridge followed by our annual Christmas party. Last year this was virtual, as it is this year, so I’m hosting again from my home office. Not what I had hoped would happen, but I’ll have some fun. Last year I had a number of shirt changes between my parts, and I may do that again.

    I know there are often annual sales awards in many companies, usually with some vacation or prize being given out, but not a lot outside of the sales department. In most of my jobs, we’ve usually had some sort of holiday party, but nothing else for most employees.

    As we approach the end of the year, I wonder if you find your organization doing any sort of recognition for your work this year? Or maybe highlighting those that have gone above and beyond what is expected? At Redgate, we have nominations in various categories. Some are sales-oriented, but we have an open award category as well as an ingeniously simple one. We’ve had people or groups from different parts of the company win that one.

    I think that recognition of effort and work accomplished is important for the morale and motivation of employees. When management recognizes people for their hard work and lets other employees have input into the process, you build a better team of people working together. Even when we aren’t the winners, we can appreciate the effort that others put into improving the organization.

    My view is that few too few in the management of organizations appreciate the value of employees, especially the knowledge workers. Replacing people is hard, and it is expensive. Unmotivated people do less work and do it less well. I hope that more organizations learn this and start to put effort into valuing those that contribute to everyone’s success.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Worse Before Better

    There was a thread on Twitter on career longevity and fixing issues inside an organization. IT notes that often there is a problem and someone is assigned or hired to fix them. Often when someone starts to dig in, they can fix some things and reduce the pain.  That’s good, as things get better.

    However, as you gain more knowledge of the issue, sometimes you realize there are more fundamental problems. If you try to fix them, you might make things worse. This could result in a repeat of the process of worsening and bettering of the problems over time. You might not make much progress if new people are constantly assigned when things get worse. If you stick with the person that is working on underlying problems, things get better over the long term. I don’t know how often I find management willing to stick with the same person.

    I think my experience has often been that organizations engage in short-term thinking. They just try to patch an issue and don’t necessarily make things better over time. I certainly saw this with supporting Windows systems in the 90s. We often rebooted machines first, which “fixed” the problem. At least for then. Often the issue would repeat, but customers could reboot their own machines.

    Is that the right approach? It could be, if a long-term fix requires lots of resources, perhaps a regular set of reboots from people is a better tradeoff. In a more complex system, usually, we find someone fixing a short-term software issue with code that is less reliable, or even less upgradable in the future. How many times do we see code that has a comment to “not touch this” or a note that the last developer didn’t understand this, but it worked. We end up with spaghetti code that no one maintains, doesn’t want to touch, and it inhibits our ability to grow and react to new requirements.

    Good fundamentals make a difference in how we build and maintain systems. This is especially true in databases, as we have to live with their design for a long time. We need to be agile, but we should apply good database modeling and integrity practices as we do so. Making quick decisions on how to add something to a schema is fine, but do so in line with best practices and an eye on the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Getting Beyond Passwords

    Most of us that work with SQL Server likely use either the Windows authentication or a user name and password when connecting to an instance in SSMS or ADS. It’s how we’ve operated for years, and likely will for some time to come. If you connect to Azure cloud resources, perhaps you use some multi-factor authentication (MFA), but that’s a minority of us.

    If this article is a picture of the real world, far too few people are using authentication beyond passwords for many services. While plenty are using fingerprints, patterns, or face recognition on a mobile device, that’s usually the extent to which they actually go beyond a password. I’ve actually started to see people using PINs on laptops instead of a password, which feels like a step backward.

    Recently I saw someone suggest MFA for SQL Server. I would hope that we would get not only more complex authentication for the platform, perhaps even two-person authentication. but I’m not holding out hope. I think the integration with AD is likely to require more steps than most administrators want to take. For now, I expect that any sort of on-premises SQL Server security is going to remain the same. For cloud databases, I do think that we will see other options as they become available.

    I personally don’t think we’ll ever get beyond all passwords. There are just too many situations where someone might not have a smart device they can access. Too many unlinked services and organizations that might not want to authenticate to GitHub, Google, Facebook, or any other large service. I certainly can’t see email moving beyond passwords entirely. We might get a login with some other service, but a password will still be a last resort.

    While I’ve gotten comfortable with quite a few different authentication mechanisms on a daily basis, I do think that the entire structure is still complex. While I often authenticate with some sort of MFA, it’s a mix of copy/pasting codes or pressing authorize buttons. That’s if I actually remember which service I used to authenticate to a particular service.

    Ultimately, I find unlocking a safe and copy/pasting passwords to be the simplest method, and I find myself often choosing to create accounts with email and passwords. Easier than me trying to track where I might have used Google v Microsoft for authentication.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • When to Use a Database

    One of the trends of the last ten years has been for many developers to try and avoid using a relational database where possible. Some look to NoSQL data stores, and others even consider flat file type stores of JSON or other formats that allow developers to work with speed and agility. Quite often it seems that applications grow to require some sort of relational store, often as an additional data store.

    I ran across an article from a data science and analysis developer that is often performing work in R or Python on datasets. At some point, the post notes that when your dataset(s) become larger than memory, you might want to consider using a local database of some sort.

    Actually, the first question the author asked was “when is your data too big?” Their answer: when operations take a long time, which was 20 seconds for the author. I tend to agree as I am looking for Notepad-like startup performance for apps, and query results in low 10s of seconds.

    Most people that perform some sort of data analysis understand tables. Whether this is in R, Python, or even Excel, the table structure for data is familiar and easy to work with. While some analysts might not be overly concerned about normalization, that isn’t always a problem for situations where data is loaded into systems and rarely (if ever) updated. In these cases, just having a database of some sort, could speed up your work.

    I think you ought to use a database early, if for no other reason than this is good practice with loading and storing data in a form that is persistent, scalable, and often can perform better across time with disparate queries and data manipulation. While quick experimentation is rapid with in-memory tools, I think a database is better suited to queries across time.

    I know I’m biased, but if you find data scientists and other analysts struggling with data sets, offer them a database. They can easily share data, you can protect it with backups, and you might find that you both learn a few things from working together.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.