Voice of the DBA

Category: Editorial

  • It Just Works

    Access is a database application that just won’t die, and it’s the subject of a short piece that discusses the reasons why the platform is still in use and thriving in some cases. I wonder how many of you still use, or support, databases that are built in Access and used by people in your organization to get work done.

    Like many SQL Server pros, I’ve often dismissed Access as a poor tool for running an important database system. However, that’s been based on my experience with larger organizations that need to scale up a system for multiple people to use concurrently. Access doesn’t do that well, though it can certainly handle a small number of people easily.

    Perhaps my disdain is also born from experience with Access being used to edit data in SQL Server and taking table locks. That usually builds a blocking chain that ends with my phone ringing, something I try to ensure doesn’t happen. However, that’s a broad brush against Access. I have a SQL Server DBA friend that used to use Access to edit lookup data. This person would even give a form in Access to a few employees to allow them to maintain some data in SQL Server. Without any issues.

    Access is easy to get up and running, which isn’t something I’d say about SQL Server. I’ve used most versions of SQL and built applications on the platform. Getting going quickly, without overhead, isn’t something I think about. Even security, which I understand well, isn’t simple to explain or get right. I see plenty of people struggling with this constantly, which is likely why many vendors end up using the “sa” account.

    There are lots of reasons why SQL Server (or some other server) is a better database platform for an application with any widespread usage. There are also reasons why Access is a good platform for small systems. I’ve run into a few Access MVPs that are still building and maintaining applications for small customers, with no shortage of work and plenty of accolades from their clients. Maybe the last part of the article says it the best why Access is still in use: ” the attraction of something that “just works” has turned many ordinary technologies into overnight sensations.” I couldn’t say it any better myself.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Learn from the Troubles of Others

    Some of us have experienced lots of strange issues while working with SQL Server. Some from poorly configured or coded systems, some from heavy workloads, and some from bugs in the code. Encountering and solving those problems, even if self-induced, is one way that we have learned about the best ways to ensure SQL Server performs extremely well under many situations.

    Others of us have had few issues and found SQL Server to be a very stable and solid product. In fact, I often find someone posting about an issue has been running an instance for years without any issues until one day something breaks or reaches a tipping point. I’ve seen this with numerous instances that were installed with plenty of disk space and without log backups. They may run for a year or more before logs fill and cause issues.

    It can be hard to plan for the unknown disasters that might be lurking in your system, but one thing that might help you think more widely about potential issues is reading posts about the issues others have encountered. Certainly plenty of people blog about these, and we often put out in our Database Weekly newsletter, but there are other good sources.

    The CSS SQL Server Engineers write some interesting posts about issues they’ve solved. Availability Groups are important and harder to configure and manage than many people realize. I caught a really interesting post about strange behavior under high workloads. This was with In-Memory technology, which I am starting to see more people experiment with implementing. This is the type of post that might give you pause, but also help you plan for and be aware of an issue that could occur.

    In this case, it’s a bug and a CU fixes the issue. Without knowing this, you might open your own case and spend time debugging the issue. Reading an article like this might trigger you to go back and check on it if you experience the issue. The bigger advantage I see here is there is a lot of information about how to measure and understand the performance of various parts of an AG system with code and linked articles here. While others might tell you there’s a CU to fix a specific issue, the knowledge you gain about how to dig into the performance of your AG setup could help you solve lots of other types of issues.

    Keep learning and keep reading. There’s lots of amazing SQL Server information on the Internet for you, and we’re happy to keep bringing some of it to you at SQLServerCentral.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Agile Job Descriptions

    Most of us have applied for a job at some point in our career. In my youth, this was finding a listing in a newspaper or on a storefront and then going in to apply in person. At times I didn’t really care what the job description was, as I needed a job. Usually the title was enough to decide if I wanted to be a “waiter” or “cashier” or “laborer”. I am somewhat glad those days are behind me, at least for the most part. My wife usually expects her fence builder and cook to be regularly available.

    In the technology fields, we often have very detailed job descriptions. In fact, I think most of the job descriptions I see have had too much input and ask for more skills than any individual is likely to have. In my experience, if I meet at least 50% of the required skills, I apply. I’d encourage you to do the same, as many of the requirements are flexible as hiring managers realize they can’t find someone that meets 100% of their desires.

    Today, I’m wondering if any of you ever look back at the job description that you were hired to fill. Does your current work match what was written when you applied? Did you end up doing more or less of what was listed? Or has the job evolved as you’ve been in this position. Would you still be qualified for this position? Over-qualified? Or maybe you feel you’re still not quite qualified enough?

    I’m kidding about the last one, though there are always people searching for a challenge and enjoying the struggle of learning and growing their skills. In fact, some of the most talented people I know have had lots of success and still struggle with impostor syndrome, which I think drives them to be better. Or maybe some just have the Jerry Rice training habits.

    Take a few minutes today and think about your job and the description that was written for it. Has it evolved, or is it what you expected?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Data Science, BI, and Reports

    Data science, along with the Artificial Intelligence (AI) and Machine Learning (ML) fields, is often seen as the new direction in which we ought to move our analysis of all the bits and bytes that we collect and store in our databases. There is so much hype now about those technologies, and managers are buying in.

    I’m not sure I agree. I do think that AI and ML will increasingly be used, but they’re just a part of what you use to analyze data. Buck Woody has a good post about the way in which we might examine our technology stacks used for BI work.

    We have a lot of reporting technologies to enable us to make better decisions, and there is a space for all of them. Many people like Excel, some use tools like Power BI and Tableau, still others prefer to get insight boiled down to a single number that influences them to move one way or the other.

    There is a lot being written about AI and ML technologies and certainly many organizations experimenting with them. Data Ccience covers these areas and more, asking our data not just what it says, but potentially what this might mean in the future.

    However, this doesn’t replace traditional BI and reporting. As Buck notes, these are tools and you should use the ones that work for your organization. Learn about them, experiment, understand the impact they have on your audience, and choose the best tools for the job.

    I’m sure this area will continue to evolve, and we’ll get new tools and techniques to help organizations make better decisions. Whether this will actually improve forecasting is likely up to the skills of both the technical and business people.

    Steve Jones