11

Ok, so this is a site that's going to have a lot of SQL. We're going to have people posting all sorts of SQL. So the intent of this post is: "What's acceptable and what's not"

SELect * frOM DUAL

SELECT Name, FirstName, UUID FROM
       MyTable

SELECT
     Name
   , FirstName
   , UUID
FROM MyTable


SELECT
     Name ,
     FirstName ,
     UUID
FROM MyTable

Now, I think we can all agree we're all adults here, and that this is just about the worst question that can be asked, but I think we can also agree that there's a bit of personal style here. So what can we rule out as just plain not allowed?

2
  • This needs to be abstracted into a DBA.SE style guide. "How to post DML questions?" Jan 6, 2011 at 5:41
  • Let's get a list going before we start trying to segment parts of it. But I agree with the sentiment.
    – jcolebrand Mod
    Jan 6, 2011 at 5:41

1 Answer 1

11

I think the best bet is to let users with edit-privs edit the nasty code into something better.

Having written 2-page SQL statements before, there's no way I'd post one of them here, but I can't think of anything that's flatly unallowable that can't be dealt with by a swift edit.

Here's my preferred style:

SELECT foo
  FROM bar
 WHERE baz=foo

But space-level formatting is far less important here.

I think our requirement should be: ALWAYS POST DDL!

A Select statement without the DDL to create it is absolutely worthless and we should make DDL statements a requirement for any question or answer that has anything but the most obvious pseudocode in it.

2
  • 4
    I agree with this, esp the ALWAYS POST DDL! part. It's in people's interest to ask readable question, so it's not really a style issue, more an issue of how we can understand what people post. Jan 6, 2011 at 10:15
  • Large blocks of supporting code/DDL that are not absolutely needed in the body of the question should be posted to gist and linked to from there. Sep 28, 2011 at 15:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .