Voice of the DBA

Category: Editorial

  • The Coffee Routine

    My daughter had a birthday recently, and one of the things she asked for as a present was a French Press. She loves coffee and is willing to wake up 15 minutes early each day to grind beans and make a nice cup of coffee each morning before high school. This has been a routine for her this past year, one that has generated requests for me to return home from my trips with new coffees for her.

    In a chat with Andy Warren recently, he mentioned that his new company has a few different coffee machines, with different choices available for employees. Some simple machines, some French Press, and other ways that employees can get their morning coffee fix. This is a small perk, but one that often goes a long way in the technology world as many developers I know aren’t morning people. They appreciate getting coffee provided by their workplace.

    This is in contrast to the situations I encountered early in my career. Back then there was no Starbucks available during my commutes, in fact, with few choices for coffee shops. I started in a large company where each department was in charge of their own coffee. We pooled money together to buy a cheap Mr. Coffee (replacing it ever year or so) and each of us contributed to fund to buy a large tin of Maxwell House every few weeks. I’m sure quite a few of you couldn’t imagine that scenario: cheap, bad coffee every day. In other companies, the same Mr. Coffee was provided, along with the buckets of ground coffee. After a decade and a half in this business, I finally worked at a company where we had a better machine.

    I was thinking about this on my recent trip to the Redgate office( after a quick stop in Copenhagen where I was instructed to be sure to get a bag of coffee for my daughter). The Redgate coffee machines (4 of them) are all located on the ground floor, in the atrium. This means that anyone wanting a cup gets to leave their desk, or make a trip before a meeting, to the open area. Lots of conversations start here, and certainly there are interactions between departments that might not otherwise occur. Plus, we have great machines, as you can see in my video.

    Despite the hassles, I visit the machines a bit too often while I’m there. At least 4 or 5 times a day, which means it’s probably good I’m not in the office full time. Now if I could only get them to put soy milk in one of the machines…

    Steve Jones

    The Voice of the DBA Podcast

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

  • More Overloads

    I was attending the SQL Nexus and SQL Bits conferences recently in Europe. These were launch events for SQL Server 2016, and the keynotes given by Microsoft included the overload of yet another SQL Server term. This time ACID was taken to be: Algorithms, Computer/Cloud, IoT, and Data. While I appreciate someone trying to be memorable or interesting in a keynote, to me, this creates confusion when we try to discuss the importance and positioning of SQL Server. ACID is a core term for relational databases, having nothing to do with the future. While some marketing people probably enjoyed this, I would have preferred they spent a little more time coming up with a term that describes a creative look at the future.

    There have been plenty of “overloaded” terms from the SQL Server platform. DAC, is that a connection or part of a database schema package? Snapshots? We have a few of them. When we talk about logs, is this meaning transaction logs or logs for the SQL Server process? Or even Agent logs. Are clusters meant to be FCIs or traditional shared storage clusters? At least that last one is close to same meaning for both terms.

    There are others, which creates confusion and could result in problems if two of think we’re discussing the same topic, but we’re not. I’d hope we’d realize there are ambiguity in a few minutes, but what if we’re dealing with a crisis? Clear meaning and understanding are important.

    I don’t mean to be pedantic, but I don’t think it’s too much to ask that new features, new concepts be given new names. While marketing might think there’s a neat sound to an old acronym, for us technical people it’s annoying, and potentially a liability. If we will continue to have marketing people influence the ever growing platform, the least we can have is creative marketing individuals that can come up with new ways to describe the hard work completed by the SQL Server development team.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Great Developers

    This editorial was originally publised on March 12, 2012. It is being re-run as Steve is on vacation.

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones

  • The Clustered Index is not the Primary Key

    I was reading through a list of links for Database Weekly and ran across this script from Pinal Dave, looking for tables where the clustered index isn’t the PK. It struck me that this is one of those facts I consider to be so simple, yet I constantly see people confusing. If you click the Primary Key icon in the SSMS/VS designers, or you specify a PK like this:

    CREATE TABLE ForSomething
  (
    SomeUniqueVal INT PRIMARY KEY
  );

    What will happen is that a clustered index is created on this field by default. It’s not the the PK must be clustered, but that SQL Server does this if you don’t tell it otherwise. Tables should have primary keys, and while you can debate that, most knowledegable SQL Server people I know want a PK on tables. There are exceptions, but if you can’t name them now, use a PK.

    However the PK isn’t a clustered index. They are separate concepts. The PK can be clustered or non-clustered, and what you choose it up to you. However, I like Kimberly Tripp’s advice. Choose the clustering key separately from the PK, keep it unique, fixed, and narrow.. If they’re the same, fine, but don’t try to make them the same. Choose what works well for your particular table, which means thinking a bit.

    You get one clustering key, and it’s worth spending five minutes debating the choice with a DBA or developer, or even post a note at SQLServerCentral. Changing the choice isn’t hard, but it can interrupt your clients’ work on your database, so try to make good design choices early, without blindly accepting defaults. It’s worth a few minutes of your time to make a good choice.

    Steve Jones

    The Voice of the DBA Podcast

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