Voice of the DBA

Category: Editorial

  • Vendor Value

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

    Software is a very interesting business. Where else can you produce a product that has zero marginal costs for additional units? Where else can you force a “maintenance” charge on your product? What other product must continue to be improved upon by the manufacturer after it’s sold?

    There actually are other industries for all of these cases, but they’re not numerous, and they differ from software. The business of building and selling software is fascinating, and I’m always learning more about it. I constantly see great questions in the forums at the Business of Software social network site. I’ll also plug the Business of Software 2009 Conference; if you’re a software person, consider attending this event. I went last year and found it very stimulating and educational, forcing me to think a lot about how that industry works.

    I happen to work for a software vendor now, Red Gate software, and I used to work for another, JD Edwards. I wasn’t a part of the development or sales in either company, but I did get to talk to people that were, and learned a bit the business. And so when I saw thisopen letter to Oracle,  it struck a bit of a chord.

    I’m not sure how software maintenance evolved to where it is today, but I think requiring it on a regular basis is an antiquated way of doing business. Microsoft doesn’t do it, though many third party vendors that work with Microsoft product do.  However I’m not sure that it’s really a value proposition for most customers.

    At least not if the software is written well. It’s a piece of junk, maybe that maintenance is required.

    I think that maintenance should be an optional part of the product, and that should fund support efforts, not a rolling cash cow to build the next version of your product. Sales fund that, or I think they should.

    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.

  • Core T-SQL

    Often I find myself wondering about the minimum bar we expect people to clear to be competent in some field. Almost all fields are evolving these days as technology and new ideas are put into practice in medicine, art, construction, law, etc. It seems as though a Renaissance is taking place with the speed and variety at which new information is spreading, usually due to advances in technology.

    In our field, working with SQL Server, we certainly see new ideas and enhancements taking place all the time. However there are also a number of core skills that evolve, but at a slower pace. For example, T-SQL grows with each new version of SQL Server, but the core language remains, and many people continue to use the knowledge they have had for years when writing code.

    This week I’m curious if we can debate about, and compile, a list of core skills with T-SQL that we think someone ought to understand to be considered competent as a database developer. I’m asking:

    What core skills should someone have with T-SQL?

    I’ll start the list, but feel free to add to it or give me your thoughts. I think someone ought to be able to understand these items and write code to solve problems that involve:

    • finding duplicate rows (grouping, joins)
    • returning aggregates of single or multiple columns (MAX, MIN, SUM, COUNT)
    • return aggregates in groups, or islands. (grouping and aggregates, windowing)
    • join multiple tables together on matching, multiple columns (joins)
    • find data in one table that doesn’t have matches in another (outer joins)
    • filtering data (WHERE)
    • subqueries and complex CTE joins of data
    • create row numbers and join back to a table without numbers (APPLY)
    • pivoting data from rows to columns

    That’s a starting list from a number of questions I’ve seen, but feel free to add your own skills you think people need.

    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 ( 20.3MB) feed

    MP4 iPod Video ( 23.4MB) feed

    MP3 Audio ( 4.8MB) feed

    Feeds are available at iTunes and Mevio

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

  • What is SQL Server not good at?

    I was reading a post that had this quote: ” The MongoDB docs tell you what it’s good at, without emphasizing what it’s not good at. ”

    This isn’t to pick on MongoDB, but the post did make me wonder what SQL Server isn’t good at? Should our docs, and BOL specifically, have warnings about when there might be problems with code? In addition to the remarks, should there be warnings about various features, functions and code? I image that the CREATE FUNCTION page might have some warning about scalar UDF performance in many situations, and I’m sure many of you would think of warnings that might be added for other features.

    I understand Microsoft might not like to point out flaws, but in the interest of building better code and applications, shouldn’t various versions of BOL, and perhaps all docs, warn the client about potential issues with using a feature in a certain way? Documenting the potential problems with using a feature in particular situations isn’t a flaw; it’s guidance about how misuse might introduce other issues.

    It’s not likely that we’ll start seeing more warnings in the official documentation, but for those of you that would like to improve the situation for others, there are always the “Community Additions” sections on all BOL pages. I don’t know if Microsoft would post your warnings there, but if they allow them, we might be able to help others understand the pitfalls of using a particular technique.

    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 ( 15.6MB) feed

    MP4 iPod Video ( 18.3MB) feed

    MP3 Audio ( 3.8MB) feed

    Feeds are available at iTunes and Mevio

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

  • It Starts with Version Control

    As a software developer, I learned about the value of version control over time. My first forays into development were as a child, where I made a single backup of my code on a separate floppy disk in the event I had an issue. This was my one-man-wolf-pack version control system, and it served me well, although it wasn’t efficient. In a few of my early development positions, we zipped up all our code each night to a separate folder, giving us the pentagram-version-control system. This worked as long as we didn’t need to go back over a week, but it still wasn’t very efficient. I think that because we worked on fairly small projects and could hold most of the code in our minds, we muddled through issues.

    Later I was introduced to a real version control system (VCS), Visual SourceSafe. Some of you cringe, but that system worked well. We could see the differences in code, and over time I learned to cut loose with my development, just trying new things, knowing that I could easily revert code backwards without much effort. Since then I’ve worked a bit with Subversion and Git, both of which seem to be very capable, mature systems. I still plan on getting some work done with Mercurial and TFS at some point, just to compare the features and functions.

    I started source controlling my databases after reading an article by Bill Wunder. This was over a decade ago, and it seemed to make sense to me. All of the things I had learned about VCS worked with databases as well, and I learned that having a database under VCS provided me with some stability in development, including the ability to roll back to previous versions of code when we found bugs. Trust me, checking out a previous version of a stored procedure is much, much less stressful than restoring an old backup just to look at stored procedure code.

    These days I see more and more people putting their databases under version control, which is comforting. It makes me think that we, as data professionals, are maturing in our industry. However there are still lots of people out there that don’t use a VCS for their database (DDL) code. Some don’t even use a VCS for their application code.

    There’s no excuse these days. Subversion and Git are free and open source. Download them, spend a few days, and get control of your code. All of the ways in which you can improve the efficiency and quality of your software start with more knowledge, and a bit of version control on which to apply your craft.

    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 ( 23.4MB) feed

    MP4 iPod Video ( 27.2MB) feed

    MP3 Audio ( 5.7MB) feed

    Feeds are available at iTunes and Mevio

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