Signs of a great SQL developer

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.

From stackoverflow

• 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.

• 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."

  RoadWarrior : These are marks of a good SQL developer, but I don't think they're sufficient to distinguish a "great" developer.

  le dorfier : OK, with the qualifier that there are conservative acrobats, and foolish acrobats.

  Bill Karwin : Yes, that was what I meant. An acrobat can exhibit impressive artistry, skill, and talent. But often there are easier ways to get from point A to point B.

• 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.

  le dorfier : I especially like the comment in regard to mispartioned functionality. I think that's more often than not the use of cursors - the dbms is being used to solve some other layer's problem.

  Ian Varley : And, as with most things ... "it depends". Various architectural and fuzzy reasons might convince one to write code on the DB that would be more appropriate on another layer, and those are times when these advanced DB features are useful.

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

• 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.