Signs of a great SQL developer

Question

Based on their work, how do you distinguish a great SQL developer?

Examples might include:

Seldom uses CURSORs, and tries to refactor them away.
Seldom uses temporary tables, and tries to refactor them away.
Handles NULL values in OUTER JOINs with confidence.
Avoids SQL extensions that are not widely implemented. Knows how to indent with elegance.

Answer 1

I don't think that cursors, temporary tables or other SQL practices are inherently bad or that their usage is a clear sign of how good a database programmer is.

I think there is the right tool for every type of problem. Sure, if you only have a hammer, everything looks like a nail. I think a great SQL programmer or database developer is a person who knows which tool is the right one in a specific situation. IMHO you can't generalize excluding specific patterns.

But a rule of thumb may be: a great database developer will find a more short and elegant solution for complex situations than the average programmer.

Answer 2

Here are a few things that don't apply to run-of-the-mill software developers, but do apply to someone with good SQL skills:

• Defines beneficial indexes, but not redundant or unused indexes.
• Employs transactions effectively.
• Values referential integrity.
• Applies normalization to database design.
• Thinks in terms of sets, not in terms of loops.
• Uses JOIN confidently.
• Knows how NULL and tri-value logic works.
• Understands the uses and benefits of query parameters.

The examples you give, of not using cursors, temp tables, or knowing 3 alternative queries for a given task, I would not consider indications of being a great SQL developer. Perhaps I would call someone who does those things an "acrobat."

Answer 3

I've found that a great SQL developer is usually also a great database designer, and will prefer to be involved in both the design and implementation of the database. That's because a bad database design can frustrate and hold back even the best developer - good SQL instincts don't always work right in the face of pathological designs, or systems where RI is poor or non-existent. So, one way to tell a great SQL developer is to test them on data modeling.

Also, a great DB developer has to have complex join logic down cold, and know exactly what the results of various multi-way joins will be in different situations. Lack of comfort with joins is the #1 cause of bad SQL code (and bad SQL design, for that matter).

As for specific syntax things, I'd hesitate at directives like:

Does not use CURSORs.

Does not use temporary tables.

Use of those techniques might allow you to tell the difference between a dangerously amateur SQL programmer (who uses them when simple relational predicates would be far better) and a decent starting SQL programmer (who knows how to do most stuff without them). However, there are many situations in real world usage where temp tables and cursors are perfectly adequate ways (sometimes, the only ways) to accomplish things (short of moving to another layer to do the processing, which is sometimes better anyway).

So, use of advanced concepts like these isn't forbidden, but unless you're clearly dealing with a SQL expert working on a really tough problem that, for some reason, doesn't lend itself to a relational solution ... yeah, they're probably warning signs.

Answer 4

Just to add to the already great answers; The developer can reduce a complex problem to something simple and easy to maintain.

Answer 5

Knows how to use INFORMATION_SCHEMA and table metadata in order to write either generic code or to code generate code in order to save repetitive database tasks.