Voice of the DBA

Author: way0utwest

  • 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.

  • Daily Coping 6 Dec 2021

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to look for new reasons to be positive about the week ahead.

    I have a few reasons.

    It’s the holiday season. I have plenty of work, but less deadlines and pressures this time of year. All of this means that while I need to keep getting things done every day, I have less stress. This means I can look forward to making progress on various things without the stress of feeling I have to get a particular thing done this week.

    I’ve scheduled lunch with a friend, so I’m looking forward to that.

    My volleyball team is coming together and making progress, so I’m enjoying the time with them, less frustration and more continuing to work on improving play.

    I’m also traveling this week, heading to the SQL Server and Azure SQL Conference in Vegas, which is exciting.

    I’m looking forward to a good week.

  • Tesla Service Challenges and the Paradigm Change

    This is part of a series that covers my experience with a Tesla Model Y.

    I had to bring my car into the service center to get the tire fixed. While I was there, doing a little work, I had the chance to interact with service personnel, but more fascinating was watching others do the same thing.

    I saw some older people that were happy with the cars, but struggling to use the technology. Maybe some of the car reviewers have a point here with the paradigm change.

    One older gentleman was struggling to get his new phone to sync as a key. He struggled with getting email logged in, a general problem with older people. He couldn’t figure out his email, and I mentally applauded the rep that was trying to help him get logged into email on his phone so that he could authorize it as a key.

    Another lady had come in for service, which she’d called to schedule. When the tech asked her to check her mobile app for instructions and approvals, she said she never looked at the app. In fact, she wasn’t carrying her phone in her purse. They worked with her to look up her account and get her car in for service.

    What was more interesting to me was that this was an integrated system, with one rep handling the walk-ins for both service and car pickup. I saw 6 people processed in the first 30 minutes by one person. At other dealerships, I’d see 10 or more people wandering around, with about the same level of inefficiency.

    My Service Experience

    When I realized my tire was leaking air slowly, I knew I’d need to do something. I reached out to the roadside service group, but they only offered a tow to the service center or a tire shop. Since I’d paid for a repair, I was looking for some credit. A tow to the repair center is less useful to me than just driving over and waiting.

    The roadside people were too busy to schedule anything in the next few days, so I decided to try the service center. I tried to schedule through the app, but I couldn’t find appointments this week in Denver. I could have driven to the Colorado Springs location, and I was tempted, but I decided to call the Denver location first. I talked with a tech who told me to come in early one day and they’d fit me in.

    I arrived and since I didn’t have an appointment, was told to call them. The only person outside at opening time was busy with a customer. I called and was told a tech would be outside in a few minutes. About 3-4 minutes later a  rep walked outside and grabbed me. I explained the issue and he checked for tires. He told me if the patch didn’t work they wouldn’t re-patch it. I needed a new tire, but he said he’d credit the patch cost.

    He scheduled me and said it would likely be about an hour as they slipped me into the schedule. I sat down with my laptop, worked about 40 minutes, and my car was done. I approved the charge in the app and paid and was on my way.

    All in all, a good service experience, and in general, faster than I’ve had in the past if I just show up.

  • 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.