Voice of the DBA

Tag: career

  • Your User Manual

    Many of us have spent time looking through manuals or the documentation for some software or product. I know I’m on the MS docs site regularly for work, and there is no shortage of times I’ve used various manuals to help me fix something around the house. We usually use a manual when we want to learn how something is supposed to work, or how to get it to do what we want.

    I saw a post on a personal user manual that I thought was a good idea for some people, maybe many people. This isn’t a manual for how you should live your life or work, but rather, how others might interact with you. This manual describes how you work, what motivates you, stimulates you, what pleases you, and even the environment in which are most productive.

    Whether or not this is something you might give to co-workers (or your boss), it likely is a good exercise for you to undertake personally. I do think this might be something you give out, but only if you have a lot of confidence it will be taken seriously and well received. Just going through the process, however, might help you better understand yourself, and you might learn something about what matters to you. Sometimes the things we think we like or want aren’t really the things that actually make us happier or more productive. I know I enjoy traveling, but too much creates a lot of stress. I like speaking in front of an audience but within certain boundaries. I like running, but my joints and bones will tell me that I really can’t have that in my life anymore.

    I’m going to make a quick, outline of my manual here. I like independent work, creative work, and the chance to decide how to do things. I like to work with deadlines, but without micromanagement. I want to be at home much of the time but go to an office and other places to interact with people periodically and regularly. I like working asynchronously most of the time, but synchronous brainstorming sessions are valuable. I like feedback to be written overall and with some thought and reasoning behind it, not a like/dislike/emotional response to my behavior.

    I think I could better flesh out different ideas with more detail and organize things better, but I enjoyed taking five minutes and thinking about my first reactions. Now I need to go back and revise this draft with a little more insight and consideration.

    Let me know today what you would think your user manual should say.

    Steve Jones

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

  • Power BI Dashboards

    This is part of a series on my preparation for the DP-900 exam. This is the Microsoft Azure Data Fundamentals, part of a number of certification paths. You can read various posts I’ve created as part of this learning experience.

    I don’t know a lot about Power BI. I’ve lightly hacked and played with it, but it has evolved and changed so quickly that I needed to dig into some concepts.

    Power BI Dashboards are a part of what you need to know for this exam. Over the years, I’ve lightly made a few reports, but not dashboards, so this was an area I needed to study up on a bit, especially these concepts.

    Dashboard Basics

    A dashboard is different from a report. A dashboard is

    • a single page
    • available in the Power BI Service only (not Power BI Desktop)
    • composed of tiles
    • can use data from one or more reports, and more than one dataset
    • one dashboard can be featured
    • supports natural language queries
    • can’t see the underlying data, but can export data

    Tile Sources

    A tile can be from:

    • a report (a visualization)
    • another dashboard
    • an Excel workbook in OneDrive for business
    • Quick Insights
    • An on-premises paginated report from Power BI Server or SSRS

    There can be standalone tiles for  images, text boxes, video, streaming data and web content.

    These are a series of facts I think are important to understand about Power BI Dashboards

  • ETL v ELT

    This is part of a series on my preparation for the DP-900 exam. This is the Microsoft Azure Data Fundamentals, part of a number of certification paths. You can read various posts I’ve created as part of this learning experience.

    I don’t have an ELT tag, and I’m not likely to make one. I tend to think of ETL as loading data somewhere, even though I know it means more.

    The important concepts for DP-900 here are that ELT is becoming more important and you need to understand what this means. I’ll cover these concepts, but also give a little overlap with where the different Azure services fit in with this.

    ETL

    For most of my career, the pattern for loading data was Extract-Transform-Load. In this pattern we:

    • grab data from a source
    • make changes to clean/change/etc.
    • write to a target (or sink)

    It’s how tools like SSIS work. They connect a source to a target and have a bunch of tasks or transforms in the middle that change the data in some way.

    This is a good pattern for getting the work done when the target system is just built for querying data, such as a data warehouse. It is also good when you need to scrub some data, perhaps for privacy reasons.

    This isn’t a good pattern when you are trying to load data quickly as the transform process takes time.

    ELT

    This is the new way of doing things. I this patter we Extract-Load-Transform, though really, it’s not a pattern that quite makes sense in that the process of moving the data just moves it.

    Here we:

    • grab data from a source
    • write it to a target

    Where’s the transform? Well, that happens on the target, often when someone queries the data. Modern analytic systems, like Snowflake and Synapse, can work with vast quantities of data, often stored in a data lake or blob system, and consume that with powerful computational capabilities. There could be some minor re-shaping of the data on write, but that’s not the idea.

    This is good when you might not read all the data. Why process (transform) what isn’t being read. Before you complain that you should know what is used, none of us know if all our data is being used. Unless we write crappy SELECT * code with no WHERE clauses.

    This is also good when we need to work at speed and privacy isn’t a concern. It’s great for the known formats of files sent to us, as the target system can project a table on top of a ser of files.

    ELT seems to be the current future direction of many analytical and warehouse systems.

  • Is the Time of the DBA Ending?

    I ran across a piece on the fall of the DBA (or part of a piece), and wondered if this is the time when the DBA is disappearing. I do know that plenty of organizations never formally adopted the DBA as a position, and plenty more have abandoned it. Not that there aren’t people managing databases, but they have moved into Database Engineer, SRE, or plain old sysadmin. They might even have another job but function as an accidental DBA.

    The DBA role has often been a mix of many things. Certainly, this is a tactical, operations role that keeps systems running, dealing with performance, security, and availability. DBAs also fix quality issues in production, deploy code changes, and often advise developers on what works well and what doesn’t. They tend to be a bit of insurance against things going wrong as well as the scapegoat when anything does go wrong. I found the DBA role to be a constantly changing, never-ending grab-bag of challenges on a regular basis.

    Those tasks don’t go away with a title change, nor with a move to the cloud, the adoption of NoSQL data stores, or the move to a DevOps style of software development. They might get handled by another role or team, but they still need to be dealt with. The DBA might need to change titles or groups, and they might need to learn how to use automation, GitOps, or some other new protocol for handling the work. As the article linked above mentions, they may need to tackle work at a higher level, not the manual, click, click repetitive process they might have followed in the past. The trend is often to work smarter, not harder.

    As with any change, there will be people who succeed and do better in the future, as well as those that find their best days behind them. I find change often brings opportunities if I am open to them and make an effort to look for those opportunities. You might find your title changes and you can ask for more compensation or more interesting work as the role changes.

    Embrace change, learn something new and find a way to make change work to your advantage. There is always a way to make this happen.

    Steve Jones

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