Voice of the DBA

Author: way0utwest

Why Can’t We Code?

Today’s editorial was originally published on June 8, 2011. It is being re-run because Steve is on vacation.

I think that most of the developers or data professionals out there have been through a variety of types of interviews in their careers. You might have had technical interviews that asked you to write code, or maybe you’ve been quizzed on SQL Server trivia or asked to explain methods and properties. Maybe you’ve had interviews with managers that had you define a few database terms. Perhaps you’ve just had someone ask you the ten common interview questions without requiring you to demonstrate any technical knowledge.

No matter what you’ve experienced, I think that many people would agree that the hiring process needs work. It does a poor job of actually predicting if the new employee can produce quality code or manage servers. Why is that?

Many companies have really tried to solve this. From the famous “How would you move Mt. Fuji?” questions at Microsoft to the common CS type questions at Google. Joel Spolsky has his own guerilla guide, which I assume has worked well for him, though on a much smaller scale. I think, however, that for the most part no one has come up with a good way to solve this issue.

A friend sent me this piece recently: Why the New Guy Can’t Code. It’s a little heavy handed, but there was one quote in there that I thought made sense: “don’t interview anyone who hasn’t accomplished anything. Ever.” It’s so easy to set up your own website, design a database on your personal machine, even put an app out for sale, that there’s no excuse not to make some effort to accomplish something. Craig Farrall talked about building something in Looking for Work in SQL Server, as did Brandie Tarvin in Changing Career Gears. It’s also one of the things I talk about at the Modern Resume: show people what you’ve done.

I don’t know that we’ll ever find a fool proof way to hire great employees, but hiring people that have proven themselves in the past, and can point to something they’ve done, is good start.

Steve Jones

July 7, 2015
I Feel Like a Magician

I ran across this comparison of SQL Server to PostgreSQL. It’s written from the point of view of a PostgreSQL developer, who certainly doesn’t like the Microsoft product much, with no shortage of complaints. Whether you agree or not, I do think there are a few valid points.

However one of the quotes that really caught my attention was in the section on converting dates. The author says that “MSDN provides a table of these magic numbers.”, referring to the arcane and completely unintuitive format codes that we use with CONVERT(). Fortunately FORMAT() was introduced in 2012, and simplifies things, but still has issues and limitations.

Certainly all systems and languages will have some codes and parameters that don’t make sense, left over from earlier times for backwards compatibility. However the more I look at T-SQL and SQL Server, the more I do find it silly that many of the small conveniences haven’t evolved across the versions. The bcp utility is outdated, functions haven’t been updated to work with more than 8,000 characters, SSIS has issues with CSV files, and more.

It does seem at times that when I’m answering questions on the Internet that the answers I give, while logical and familiar to me, seem magic to others. This might be especially true when talking about transaction logs, which still seem far to difficult for many people to grasp.

I enjoy working with SQL Server and look forward to a long career in the future developing software on the platform, however I do worry about some of the long term health of the platform for new users. It seems that the usability advantages of SQL Server have dramatically narrowed in recent years, and in some ways the other platforms have implemented features that SQL Server is sorely lacking.

Hopefully Microsoft will focus on reducing the friction of manipulating data in SQL Server. Not that SQL Server will go away, but I can see companies migrating to other platforms if it becomes substantially easier and cheaper to manipulate data.

Steve Jones

The Voice of the DBA Podcast

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

July 6, 2015
Half a Year

Today is a holiday for much of the US workforce. Tomorrow is Independence Day, though we have another year until the sequel of the movie by that name. This is the day the US started down the road of becoming a country, and if you’re a US citizen, i’d urge you to take a few minutes and look back at our declaration.

Half a year is gone in 2015. It’s amazing to think that this year is already halfway gone. At the beginning of 2015, we had little information on the next version of SQL Server, though we had a preview of some features, like Row-Level Security (RLS), in January. Now we have CTP 2.1 and a lot of features that are being added. We’ve added some jumpstart links for Learning SQL Server 2016, so if today is quiet, check out an area and learn a bit about what’s coming.

We continue to see data loss incidents on a regular basis. It’s almost becoming a piece of news that we are desensitized to hearing. I’m not sure if it’s good or bad, but I don’t think the financial penalties are high enough to get companies taking it more seriously, or certainly not serious enough to ensure developers change their ways they build applications. If you doubt the issues here, read Troy Hunt’s blog. He regularly finds companies not implementing security well.

All in all it’s been a good year for technology and it’s exciting to see many products changing, technologies maturing, and more options than ever for building software. I hope you have a great holiday weekend in the US, and a pleasant one elsewhere.

Steve Jones

July 3, 2015
Defining Foreign Keys at Table Create Time
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

How many of you can define a foreign key when you create the table? Probably a few of you, but I bet most of you are like me and don’t necessarily know the syntax. I have often defined these later, which is fine. As long as they get defined.

However I knew I needed a specific key when I was creating a table and couldn’t remember the syntax, so I had to search and learn how. I used Google and saw a few links from MSDN, but those tend to be overly documentation heavy. One of the links was to SQL Authority, run by Pinal Dave. He does a great job of simplifying things (and he’s a friend), so I followed that link. I could see the syntax and tested it in minutes.

It’s easy to create a Primary Key in CREATE TABLE, and I wrote about that for one of my first SQLNewBlogger posts. The Foreign Key is similar, but not quite as simple.

Imagine that I have a parent table:
```
CREATE TABLE orders
  (
    orderid INT IDENTITY(1, 1) CONSTRAINT Orders_PK PRIMARY KEY ( orderid )
  , orderdate DATETIME
  , complete BIT
  );
GO
```
I now want to create a child table and link the orderid in the child to the parent. I can do it like this:
```
CREATE TABLE OrderLines
  (
    orderlineid INT
      IDENTITY(1, 1) CONSTRAINT OrderLines_PK PRIMARY KEY ( orderlineid )
  , orderid INT
      CONSTRAINT orderlines_order_fk FOREIGN KEY REFERENCES orders ( orderid )
  , qty INT
  );
GO
```
Note that I define a constraint inline, just as I did for the parent. However I note this one is an FK and it "references" another table. In this case, I list the Orders table and put the columns in parenthesis.

Quick, easy, build your FKs inline when you know about them in advance.

SQLNewBlogger

While trying to remember how to create an FK, I ran a search and chose the reference below to start. A matter of seconds had me seeing the syntax and writing the code.

Putting this together was less than ten minutes.

References

Creating Primary Key and Foreign Key Constraints – http://blog.sqlauthority.com/2008/09/08/sql-server-%E2%80%93-2008-creating-primary-key-foreign-key-and-default-constraint/
July 2, 2015