Voice of the DBA

Category: Editorial

  • Independence Day 2017

    Today is July 4, Independence Day in the US, more commonly known as the Fourth of July. This is the day that the United States declared it self a separate nation from the British Empire. For most of my life, this has been a day of celebration with kids, or as a kid. A time when we cook outside, watch fireworks, and have an enjoyable day away from work. The last decade or so I’ve also re-read the Declaration of Independence, as a way of remembering the history of my country.

    As I was preparing for this year’s holiday, it struck me that so often inside of companies we find groups and departments that almost separate themselves from others. We get silos and habits of working that are distinct, often because they feel that trying to work within the constraints of others’ requirements is too stifling or non-productive. Unlike the U.S .Declaration of Independence, I’m not sure that most of the people that work separately could list a defined set of reasons why they work by themselves.

    As I talk about and promote DevOps, the one fundamental action needed for success is communication. Disparate groups need to work together, from architecture to development to business analysts to QA to operations. Every person needs to provide help and feedback to other groups, being willing to modifty the ways in which they work to smooth the out the entire process.

    In other words, we need to work together.

    I hope that as you move forward in building software for your company, you learn to work with others, finding ways to smooth out the process to deliver valuable features and functions to your customers.

    And if you’re in the US, have a great Fourth of July.

    Steve Jones

     

  • Backup Preparations

    I’m sure that many data professionals recognize the importance of having backups in the event of some issue. Many of you will schedule these as soon as you create a database, and then not think much of the process, ignoring it as long as the backup job continues to run.

    As you gain experience, you may even set up backups on new instances and versions without much thought, assuming you know how the process works. That’s probably true of SQL Server, as the backup system and structure hasn’t changed for years. However, do you think backups work the same on other platforms, such as Oracle, PostgreSQL, or MySQL? What about MongoDB or Neo4j? Don’t we just run the backup command to a file and the restore from file sequence if there is an issue?

    Backups aren’t the same on all platforms, and they may function differently enough that you can find you aren’t prepared for a disaster situation. I was considering this over the last week as I read about the challenges of restoring from Azure SQL Database and Amazon RDS. With the popularity of both cloud computing and SQL Server, we have a few different flavors of platforms between on-premises installs, AWS, Azure, and likely other hosted solutions.

    Whenever you work on a new platform, even if it’s a variant of one you have experience working with, there is a chance that the techniques and commands you run to manage backup or restore will change. Since a restore situation is often a stressful event, with the pressure of an RTO upon you, this isn’t the time to learn that your backup preparations are inadequate.

    As much as I might joke about ensuring your resume is up to date in case of a restore problem, I would emphasize that your resume isn’t going to be as helpful if you are negligent and unprepared because you haven’t done everything you could to be ready for a disaster. While your employer might not allocate enough disk space or other resources to ensure their RTO and RPO can be met, you can certainly ensure that your skills, knowledge, and recommendations aren’t the reason that data is lost.

    I periodically practice restores, I’ll take a tail log backup, I’ll ensure that I understand how to export a BACPAC, all to be sure that my skills are up to date. I don’t want to encounter a situation where I need a filegroup, point in time, or striped backup restore and not know what I’m doing. You might want to do the same, taking time every month to ensure that you perform some different restore technique. Just in case disaster strikes next week.

    Steve Jones

  • The 43rd Birthday for SQL

    I ran across a neat post that reminded me that SQL is 43 this year. It first appeared in 1974, and not only is it still in use by many of us on a daily basis, it’s the second most common language in the Stack Overflow developer survey. Only Javascript is more commonly used, which is also somewhat amazing. Maybe Javascript really is taking over the world.

    I’m not surprised that SQL is so heavily used (half the developers report it’s one of their languages), since almost every application needs to query data from a database. Whether you use a relational store or not, SQL is likely your language of choice. Many NoSQL database technologies have bolted some SQL query capabilities onto their systems precisely because SQL is handy and helpful in sifting through lots of data.

    I think SQL is a mess of a language in many ways. The DDL is poorly crafted, and even the DML reads funny to me. The order of operations is nothing like the structure of the query. I’d expect more of a LINQ like syntax (where is the data coming from first) that logically flows the query from data to result. I’m sure that will not change anytime soon since we’re so used to the SQL language. Even those developers that like to write in LINQ really need to know SQL in order to check their queries against back end systems. The survey of loved languages backs up the idea that SQL isn’t great it falls far behind many other languages. However, many of those are more modern languages that provide more convenience and help. SQL is fairly bare bones, with rather immature tooling for a 43 year old.

    SQL Server is also doing well, showing up in almost a third of developers’ work, ahead of PostgreSQL, Oracle, and beaten out by MySQL. That’s a testament to the power, ease, and feature rich nature of SQL Server. I wonder if the release of SQL Server on Linux will grow these numbers. My thought is that those companies using another platform on Linux might consider SQL Server instead, perhaps because the robust nature of the platform along with the ease of development may get more people to try it. We’ll have to check back in a year.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • A Database Design Test

    I was watching a presentation recently on database design and the speaker talked about how he hires developers. These are full stack developers, for whom the database is a portion of their responsibility. One of the tasks he gives them is a short database design test, designed to get a rough idea of their knowledge of databases.

    The test is a short story, with a classroom/course/scheduling scenario. There are descriptions in some business terms, and the instructions ask the reader to to decide how to put entities together and link them. There is a sample unlabeled diagram with only a couple boxes. The diagram is meant to clue them in to the way to indicate relationships, and there are names of different structures in the test in bold. For someone experienced in databases, this would seem trivial as the entities are listed in bold, and the test is designed to be completed in 5 minutes. Extra points for not crossing any relationship lines.

    I found this to be a nice, short test to gauge a developer’s knowledge. The speaker noted that they didn’t worry too much about time taken, or the exact notation used in the digram. This is mostly a way to measure if an individual thinks in terms of entities and connections. This is part of a few tests used for a basic evaluation of how a developer solves practical problems, and avoids the trivia based examination used by many interviewers.

    I was intrigued since I’ve never been really asked to design anything and I’ve had quite a few jobs where that would be a portion of my job duties. No one has given me a scenario and asked me to produce an ER diagram. The most I’ve gotten is some theoretical questions on normalization, or what keys are. I wonder if I’m alone. For those of you reading this, have you ever had a design test of any kind in an interview? Can you disclose the types of questions or scenarios? When were you tested? It would be interesting to see if this is used by much of anyone.

    There seem to be so few ER diagrams in the real world, especially from vendors, who should always produce one for clients. I suspect that few people understand them, or even write them, even though they can be invaluable when trying to write reports and understand the relationships between different entities. Many ask, but could those people produce one? Or read it beyond realizing which field in table a connects to which field in table b? Let me know this week if you’ve been tested on your database design skills.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.