Assuming a SQL query is well-formed, works correctly, and meets the other general criteria for appropriate reviewable code here, are SQL query reviews on topic? If so, is there a threshold of complexity (subjective, or somehow objective although I don't know what that criteria could be) below which the query would not be welcome?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
5
A good place to find out about the rules you're asking for is by looking at the sql tag. The brief description says:
Structured Query Language is a language for interacting with relational databases. Read the tag wiki's guidelines for requesting SQL reviews: 1) Provide context, 2) Include the schema, 3) If asking about performance, include indexes and the output of EXPLAIN SELECT.
The more detailed tag wiki is at the [info] tab on the tag's page:
-
2\$\begingroup\$ Which, of course, I should have done before asking, I guess I just got excited about the question. Thanks! \$\endgroup\$– Jason CApr 29, 2017 at 17:32
-
1\$\begingroup\$ @JasonC no probs. You might want to give a re-read to how-to-ask and on-topic as well, to make the most out of your first question on CR. \$\endgroup\$– janosApr 29, 2017 at 17:41
-
3\$\begingroup\$ That "Provide context" can't be stressed enough. Related: codereview.meta.stackexchange.com/q/1226/31562 \$\endgroup\$ Apr 29, 2017 at 19:28
-
\$\begingroup\$ When reviewing performance, I usually provide/request the actual execution plan. Would that be worthwhile in this context, or overkill? What about client or network statistics? \$\endgroup\$– PaurianMay 1, 2017 at 17:27
-
\$\begingroup\$ @Paurian Providing an 'overkill' of context isn't easy on Code Review. We like context. You really have to put it on thick before we'll say it's too much. \$\endgroup\$– Mast ModMay 2, 2017 at 12:18
\$\begingroup\$
\$\endgroup\$
To add to janos' answer, as one of the most frequent SQL reviewers, my view is that SQL-only questions are fine, as long as the code works (and we usually go with the OP's word, since we can't log in to their server and run it).
However, what makes answering SQL questions problematic is that many askers don't give much or any information about the design of the tables, as in, which columns are PK/FK, what indexing they have, etc.
So a "good" SQL question should ideally include that information as well as the query code to be reviewed.