Voice of the DBA

Category: Editorial

  • The NoSQL Rise and Fall

    I’m not sure this blog that seems to talk about the problems of NoSQL databases in general makes a lot of sense. If you read the comments, you certainly see lots of complaints, but I also think the post isn’t well written. It lists the problems of RDBMSes as possibly deleting all tables while changing a key or being unable to add a column easily. While I don’t know about all RDBMSes, I don’t know any that could lose all data with anything less than DROP DATABASE.

    At the same time, the NoSQL complaints and problems seem to be generally presented, which isn’t good. The various NoSQL flavors of databases vary widely and the way you look at a columnar or graph database is much different than a document database. Really, the piece ought to be separated to look at a certain class of NoSQL database compared with RDBMSes.

    That being said, I do see less hype around NoSQL in general. The class of problems handled by various types of databases vary, and I am sure that lots of people using NoSQL databases are quite pleased with them. At the same time, I’m not sure a lot of the RDBMSes did get replaced or continue to get replaced. RDBMSes have a lot of value and we have a lot of experience, both as developers and administrators.

    There might be a shortage of NoSQL (pick a type) administrators for operating the databases. Even in some of the famous companies that use them, I find developers often explaining a RCA or the troubleshooting of a particular process. While that might be a choice that an organization makes, a lot of developers that I know don’t want to be supporting systems very often, especially at night and on weekends. A couple of bad incidents usually has developers wondering why there isn’t an expert on the Operations staff.

    I do think that many of benefits of different types of NoSQL databases are a bit over-hyped. Not that a graph database can’t handle your e-commerce system, but it likely takes a lot of code, and likely a lot of mistakes in getting it to work well. I also feel that some of the downsides of RDBMSes are minimized. They are a pain for application developers to work with, and the SQL language isn’t very sensible.

    That being said, we have a lot of experience with these databases, and that should not be discounted. Productivity is a big advantage in trying to build new software in a flexible manner. I am all for experimenting with different platforms to understand where they work well, but also learn to use your existing RDBMS platform well. Write better code and you might be surprised just how scalable your system proves itself to be.

    Steve Jones

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

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