6

The question has already arisen (imagine that) and at some point we'll need a faq-like to answer this question, but this is not the FAQ on SQL or on DBA.SE and so we'll start here and we'll make a new post later for the FAQ. Bear that in mind when forming and judging answers to this question.

What actually constitutes a SQL question and what constitutes a question that would be better suited for one of the other tags?

I've started by including all the tags currently present here that can be used (AFAIK) in a SQL context because I think to start with and organize thoughts it would be easier to EXCLUDE rather than define what INCLUDES a SQL question. I could be wrong on this. But it's the tack I chose to take. This is my first time on a private beta too ;)

  • The tag in question:

    sql

  • The platforms/tools we should be able to exclude:

    innodb           ms-access        mssql            myisam
mysql            mysql-5          oracle           oracle-11g-r2
oracle11gr2      phpmyadmin       postgresql       sql-server
sql-server-2005  sql-server-2008  sqlite

  • The tags that are pretty clearly not SQL questions:

    app-sec          benchmark        best-practices   bioinformatics 
biology          blogs            books            career         
client-server    coredata         couchdb          data-warehouse
db2              document-oriented                 erd
erlang           etl              google-app-engine
learning         management       mariadb          migration
mnesia           model            mongodb          monitoring
mysqldump        nosql            process          proxy-connections
puzzles          rdbms            relational       schemaless
security         slony-i          slow-log         source-control
sphinx           storage-engine   support          tools
tree             tweek            uniprot          vendor-support
wallet           windows

  • The remaining tags to be discussed:

    • aggregate
    • audit
    • authentication
    • authorization
    • backup
    • columns
    • comparison
    • conditional-index
    • config
    • constraint
    • database-design
    • database-link
    • deadlock
    • delete
    • embedded
    • empty-string
    • explain-plan
    • foreign-key
    • index
    • join
    • logging
    • no-value
    • normalization
    • null
    • optimization
    • password
    • performance
    • performance-testing
    • primary-key
    • query
    • race-conditions
    • regular-expression
    • replication
    • schema
    • sql-injection
    • stored-procedures
    • syntax
    • testing
    • triggers
    • xml

My thinking is that if it shows up on the bulleted list then it probably doesn't need to have the SQL tag too, or rather it needs to have the tag listed rather than the SQL tag.

Ok, now for feedback

1

1 Answer 1

Reset to default
2

An SQL question has something to do with Structured Query Language. While there may be some questions that have the SQL tag that could do without it, it seems to me that removing it too aggressively would not be beneficial.

For example, from your discussion list performance with the SQL tag may be asking about how a particular SQL statement will perform, whereas without the SQL tag it may be asking database performance unrelated to a particular SQL statement.

null could be asking about null values in a table or procedure vs. using null in an SQL statement.

regular-expression could be asking about use in a package rather than in an SQL statement.

Even when the tag seems redundant as with the join tag, if the join is part of an SQL statement I don’t see why it would be a problem to have both tags.

I’m even concerned about the tags you list as pretty clearly not SQL questions. For example, if I have an SQL problem that only seems to occur on the windows platform, why would I not want to tag it with windows and sql? If a puzzle is an SQL puzzle, then puzzle seems appropriate. If I have a problem with an SQL statement on DB2 then db2 seems to be the only logical option.

If I did not understand the point of your question, then please clarify.

6
  • 1
    My intent is "when should the SQL tag be used". Maybe I should retitle it ... And to be fair, it was a question someone else had raised on meta.dba and I was trying to get it worked in as a question that will need addressing at some point in the future.
    – jcolebrand Mod
    Jan 5, 2011 at 16:26
  • 2
    Then the SQL tag should be used whenever the question relates to SQL without regard to other tags.
    – Leigh Riffel
    Jan 5, 2011 at 16:46
  • @Leigh ~ So you think it should carry the SQL tag no matter what if it discusses SQL?
    – jcolebrand Mod
    Jan 5, 2011 at 21:44
  • 1
    No, I just don't think the presence of other tags should be a determining factor. The question itself should determine the use not other tags.
    – Leigh Riffel
    Jan 5, 2011 at 22:11
  • 1
    @Leigh I see what you mean, and I'm definitely not opposed to this. Just trying to build some community concept, ya know? If you're the only responder here for the next five days then we'll have a pretty good idea that the community doesn't disagree.
    – jcolebrand Mod
    Jan 6, 2011 at 2:13
  • 1
    Sounds good. I am certainly not opposed to removing the tag when it doesn't apply to the question and can see how it could easily be over used.
    – Leigh Riffel
    Jan 6, 2011 at 16:37

You must log in to answer this question.

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