Voice of the DBA

Category: Editorial

  • Competition or Cooperation

    I once worked in a company with a stack ranking system. I was a manager, and hated the idea of ranking the people reporting to me in this system. I had a good staff, managing all three major RDBMS platforms (Oracle, DB2, SQL Server), and they performed their jobs well. At review time, when I was told I had to have some 2s (on a scale of 1-5) in addition to 3s and 4s, I was distressed. Having worked with and managed hundreds of people in my career, none of my staff was below expectations (a “2”). However I had to rank at least one person at that level.

    Microsoft has had this “stack ranking system” for years, and there has been plenty of speculation that it hasn’t encouraged the really talented people to work together, but instead it pushed employees apart. Apparently they’ve decided to move away from this system according to numerous reports. I have heard that the most talented people tried to ensure they weren’t working on the same team with other talented people, just to ensure they would continue to be highly ranked.

    I believe in teams. I believe in getting people to work together, and help each other. I know that successful software projects, those that require more than one developer, are never successes or failures because of one person. I know people contribute more or less than others, but the strength and value of those contributions are not strictly individual talent or effort. We need talented coders to solve tough problems, and we need average programmers to tackle mundane tasks. Both are necessary (along with many other roles) to ensure success of a project.

    Cooperation, assistance, teaching, learning, working together as a team, with each person helping the others to succeed is how I like to work. We don’t need winners and losers; we need success from everyone.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 21.5MB) feed

    MP4 iPod Video ( 21.5MB) feed

    MP3 Audio ( 5.1MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Data Preservation

    Maintaining data across time isn’t something many of us think about. We work with data in the here and now, and in the database world, we typically only need to recover or restore data from a short window. Like most of you, I would usually plan on recovering data that’s only a few days old. Being forced to restore a database from two weeks on any of my systems would make me cringe. It certainly would be embarrassing for me personally if it were my fault I couldn’t restore to a point in time that was more recent than that.

    In planning to recover our systems, we typically know the versions of software we have to recover from, and we can easily re-download copies of SQL Server or the patches we need. Most of us are dealing with SQL Server 2000 or later, which is good since those are the only versions still documented on MSDN. If you need SQL Server 7.0 or SQL Server v6.5 documentation, I hope you have copies.  The same goes for the media. You can still download SQL Server v6.5, and SP5, but if you needed SP3, it isn’t easily available. I ran into that situation about 10 years ago, and we had to make a special request through our TAP manager to get someone in Redmond to dig up a copy.

    In some ways it might not be important to worry about long term storage. Most of us will end up transferring our data to newer systems (and formats) over time. As we upgrade SQL Server, our databases move along to newer formats, or we abandon them because they are no longer needed. That’s fine for some data, but not all.

    Long term archival and storage is a challenge, as you can see in this short look at how old films are maintained. It just touches the edges of what’s being done, and doesn’t address costs. Plenty of old films have been lost forever, and perhaps that doesn’t matter, but it does concern me. I have thousands, maybe tens of thousands of digital images. While I love the ease with which I can share them with family, and make extra copies, I am worried that perhaps the lack of a physical copy means my great-grandchildren will struggle to find evidence of my generation if there is a catastrophe or storage formats change.

    This is one area of our industry in which we have a lot of maturing to do, and I hope that we can come up with some new ideas for maintaining our data for the long term, across not months or years, but decades or centuries.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo atwww.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 18.9MB) feed

    MP4 iPod Video ( 22.0MB) feed

    MP3 Audio ( 4.5MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Is Your Data Relational?

    When should you use MongoDB? I’ve asked that question a few times, and I haven’t gotten a good answer I understand. I’ve read about a few of the NoSQL, document databases, and I think they do have a place in the world. There are domains of problems that they solve better than relational databases. I’m sure that streaming databases, graph databases, columnar databases, and more have places where we they shine, but I still believe that many, perhaps most, problems are best solved by relational databases.

    I saw this piece about MongoDB being a poor choice by the Diaspora developers because they hadn’t modeled their data well. It’s a decent analysis of a real situation, and I think it’s one that has probably been repeated many times by many developers that were intimidated, frustrated, or otherwise turned off by relational platforms.

    There is a cost to using a relational platform, and it can require expensive developer time to map objects to relational structures. However the solution isn’t to abandon the relational platform. The better solution is likely to train developers and hire a few DBAs that can help with the mapping and queries to solve problems.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( MB) feed

    MP4 iPod Video ( 17.0MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Checking Up on Developers

    This editorial was originally published on May 8, 2009. It is being re-run as Steve is on vacation.

    The other day I was reading Brad McGeHee’s post on duplicate indexes, and it struck a chord with me. That same issue is one I’ve seen many times with in house applications. Developers don’t understand indexing, they create one clustered index (CI) as the PK, and then they create the same index as a nonclustered (NCI) one. Either they don’t realize that the PK is an index, or they are ignorant of the differences between a CI and an NCI.

    What’s worse is that I see it in third party applications as well. If you’re selling a product, I think you ought to know how to tune it for a database. If you don’t, I’d like to see some recourse for clients. Maybe some common settlement in a lawsuit. A few of those and I bet you’d have more DBAs hired by software firms.

    Or a little more training for developers.

    For this Friday’s poll, I wanted to pick on developers a little. I like developers, I appreciate the work they do creating some great applications I use, but I also think they make some silly database mistakes. So this week:

    What are common mistakes developers make in SQL Server?

    Indexing is one area, but what other things do you see a lot from developers? I’m thinking a good list of mistakes here might be a nice checklist to go over with developers as they complete an application. It could be in code reviews, QA, pre-purchase requirements, RFPs, any number of places.

    I’ll add one more indexing issue that I’ve seen often in third party applications. Too often I’ve seen developers create a separate index on every single field in a table. For all tables! I realize that indexes improve query performance, but it does create an issue with inserts/updates, and space. Space isn’t an issue as much as it was in the past, but as data sizes get larger, I would not be surprised to see this becoming a problem in some applications. More indexes also impact backup time and size.

    Give us a response this Friday of the common mistakes that you see developers making, and that you wish they’d learn to avoid.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.