Voice of the DBA

Category: Editorial

  • The Battlefield of Your Career

    Jeff Atwood has had quite a bit of success in his career, having been a founder of StackExchange and Discourse. He’s a fellow alumnus of the University of Virginia, along with Alexis Ohanian. Both of them have had a higher profile than me, and I admire what they’ve accomplished. I also think they’ve both been advocates for the technology industry, helping and advising others on how they can succeed in their own careers.

    Jeff has been writing interesting posts about hardware and software for years, but the latest one struck me. It’s called Learning on the Battlefield, and it has a lot of the same advice that I recently gave someone. In the post, Jeff notes that approaching your software career is like learning on the battlefield. It’s like making weapons and coming up with tactics. You really need to test them on the battlefield.

    Note, I wouldn’t expect that this means we test ideas in production, but rather, that we do test them in a live way, actually using the software. In QA, of course.

    Jeff notes that the work of building software is more important than schooling. I agree. I also think that the closer you can get to simulating work, the better off you are when you interview, or even when someone examines your body of work. His advice is to get an internship, go to user groups, build OSS, publish articles, and blog.

    All of these things are raising your brand. That’s a lot of what I’ve been writing and speaking about for over a decade. It’s the advice I gave someone recently who wanted to not build software, but become a DBA. Do the work, set up a test lab at home, in Azure or AWS, and then write about it. Blog about what you learn, how you do things, what others advised you about, and even the mistakes you’ve made.

    Don’t be perfect, don’t try to show a hiring manager you know everything, but rather show them that you know some things and can learn others. We all make mistakes, even those of us that blog a lot. We can write about mistakes and still impress people.

    Make your job search, your career advancement, or your desire for a raise/promotion/project, a battlefield. Do things and share your experience. Tell us about your first year of something, and more importantly, learn to practice communication. Add this to your CV/resume as a body of work, and I am sure that you will find it helps your career.

    Steve Jones

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

  • Do You Still Use CHAR?

    I ran across an article, titled When to use CHAR, VARCHAR, or VARCHAR(MAX), which struck me as something I never do. I mean, I do use varchar (and nvarchar), but I can’t remember the last time I actually created a char column. The article is worth a read, and it sets the stage for you to think about your database design process and the choices you make.

    It’s Friday, and if you take a few minutes and think about the last few times you’ve added columns to a table have you used CHAR as a data type? Or do you default to varchar of any size as a general rule?

    I tend to do a lot of demo work, and I help customers with different situations. In many cases, we are storing text data, often not strongly typed data. As a result, I find most customers using varchar (or nvarchar), and I’ve built the habit of using the variable structures in proofs-of-concept and demos. I find it especially handy when someone asks me to enter some data they use and then show how it would be handled.

    Early in my career, I’d often tag a zipcode as a 5 character field, or a state as a 2 character abbreviation. However, these days a postal code can be a 5+4, which is 9 characters or even 10 with the plus. Many companies work overseas and may want to account for longer postal codes. States (or regions), can often be 3 characters, but sometimes more. Often we just leave 10 characters for region abbreviations (or longer) as the data might be spelled out or need to accommodate something unknown.

    For many business applications, it seems that there might be a definition for what the data should be, but since exceptions can abound, often using a variable-length data type just prevents issues in the future. Add that to the fact that often we are dealing with cheap storage, and it doesn’t seem worth the time to try and get the exact size correct. Even when knowing an invoice uses 10 characters, are you sure that you won’t exceed the ten-character width? What if you acquire a company that uses 12 character invoice numbers? Easier to set this to a variable 20 and move on.

    If you work in data warehousing, then you might know what your data sources contain and be more likely to choose fixed types, but is the space savings worth the work in the event that source systems change? I don’t know. I tend to plan for sources to change and allow a little padding in my schema. You might feel differently, but are the space savings worth the potential hassles in the future? I’d be curious what you think today.

    Steve Jones

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

  • The Cloud as a Foundation

    The cloud for computing is a fascinating structure. I know there are plenty of jokes about the cloud just being someone else’s computer, and there are good reasons not to use the cloud. However, there are also lots of good reasons to use the cloud. Whether you choose to embrace it or avoid it, cloud computing is going to be a part of our careers for a long time. The use is growing, and more and more companies are shifting workloads to cloud services.

    How that will evolve, especially for data-intensive systems, will be fascinating. One of the interesting changes that seems to be taking places is the growth of database and data stores that fulfill specialized roles for customers. Snowflake might be one of the most well-known examples, but there are plenty more. The number of offerings is growing, and perhaps this is another evolution of how the cloud will integrate into more businesses.

    To date, most of the large cloud providers (Azure, AWS, GCP) are offering a full stack of different systems that you use to deploy code and run applications. These cobbled-together services and platforms often lock customers into a particular cloud, though that isn’t what many organizations would like. Especially in some regulated industries that mandate multiple clouds be used for redundancy. This article talks about the cloud as a foundation on which other customers can build services or platforms, especially data platforms.

    This is something I would like to see. Snowflake is something that a company can run on AWS, Azure, or GCP.  CockroachDB is another that allows customers to work with the platform on the provider of their choice. I like the idea of a wider set of platforms built upon cloud providers, but in a way that allows customers to move if need be, and also pressures cloud providers to keep pricing in line with each other.

    In my mind, the more we find innovative companies building cloud-native data stores and other products, the more pressure on existing companies to improve their offerings. Competition is good, and it brings us new tools, while also forcing existing companies to update their offerings. It’s not perfect, as sometimes we get new features without quality improvements in the base product, but without competition, we might not get that anyway.

    I am fascinated and pleased by the cloud. The more I learn and work with it, the more I appreciate this as a truly new way of approaching the building and operating of software.

    Steve Jones

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

  • Speedy Break Fix

    I received a report at SSC of a missing toolbar in the forums. I checked, and sure enough, the toolbar for formatting code and text in responses was missing. I submitted a high-priority ticket, mostly because I hate unformatted code. The site was still usable, but people would be posting stuff that just didn’t look good. The developers got to work and had a fix, but it still wasn’t right. The wrong toolbar was showing. This was a generic toolbar, not the one that we have had for years (this one). They produced a second fix that contained the right toolbar.

    The developers are in and out of the SQL Server Central codebase, working for a few days on open issues, then busy with other work for a week or two. They work in a DevOps style environment, with changes run through a Pull request/peer-review process, then CI, then an automated deployment. They often can make a change and deploy it in hours, or even minutes.

    Is this a bad process?

    It would be easy to say that the developers were moving too fast in their deployments and not testing things. However, the issue in production wasn’t easily reproduced locally, and we found a few places where local dev environments don’t quite match live. That’s been an ongoing problem for as long as we’ve been developing software outside of production. The DevOps solution here is to adjust the environment setup in code so that dev does match production closer. I’d say this is my solution, but likely we’ll find something else in the future that isn’t the same and we will continue to need to adjust something to get the environments in sync.

    What’s the alternative? We could go slower and batch up a bunch of changes, testing them all, moving at a more waterfall-ish cadence. Would we catch this? Perhaps. However, we might not, and if we are batching changes, then bugs live for a longer time in production until we perform a new release.

    Or we could build a quick patch, in one of two ways. One is by moving quickly, at an agile/DevOps speed, to quickly build a patch. That’s a hacky, not-thought-through flow that many people use to fix a deployment, usually without the process and bounds that a good DevOps process provides.

    The other option is to bundle a fix in the next release, which could be next week? Next month? Who knows. Slow processes don’t necessarily make the final code better and can prevent rapid fixes.

    Ultimately my feedback from here to the project manager is that we need a test, a process, or something that checks for these issues before release. While I know something else could break, I prefer these small deployments taking place often, with bumpers to limit the regressions we know about.

    Steve Jones

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