tags:

views:

2376

answers:

7

After reading a couple of answers and comments on some SQL questions here, and also hearing that a friend of mine works at a place which has a policy which bans them, I'm wondering if there's anything wrong with using backticks around field names in MySQL.

That is:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...
+2  A: 

Well, as far as I know, the whole purpose of using backticks is so you can use names that coincide with reserved keywords. So, if the name isn't colliding with a reserved keyword, I don't see any reason to use backticks. But, that's no reason to ban them, either.

Chris Jester-Young
+3  A: 

To me it makes a lot of sense to use them at all times when dealing with field names.

  • Firstly, once you get into the habit, it doesn't hurt to just hit the backtick key.
  • Secondly, to me, it makes it easier to see what exactly are the fields in your query, and what are keywords or methods.
  • Lastly, it allows you to use whatever field name you wish when designing your table. Sometimes it makes a lot of sense to name a field "key", "order", or "values"... all of which require backticks when referring to them.
nickf
You should also add that it protects you from any future reserved words being used (which has bitten me before).
alex
+5  A: 

The only problem with backticks is that they are not ANSI-SQL compliant, e.g. they don't work in SQL Server.

If there is a chance you would have to port your SQL to another database, use double quotes.

Alexander Kojevnikov
Yep. Use MySQL's ANSI mode - http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html - to enable double-quotes in MySQL and thus regain cross-database compatibility. Backticks/quotes are also necessary because you never know what's going to become a reserved word in future DBMS versions.
bobince
That's very true! One of our server applications was running fine until we applied an upgrade to our database engine, which added a new keyword. Suddenly everything that queried a particular table broke.
Miquella
@bobince When I was *new* to dev, I named a column `range` or something like that. When we upgraded to MySQL 5 it failed because it was a new reserved word!
alex
+11  A: 

Using backticks permits you to use alternative characters. In query writing its not such a problem, but if one assumes you can just use backticks, I would assume it lets you get away with ridiculous stuff like

SELECT `id`, `my name`, `another field` , `field,with,comma`

Which does of course generate badly named tables.

If you're just being concise I don't see a problem with it, you'll note if you run your query as such

EXPLAIN EXTENDED Select foo,bar,baz

The generated warning that comes back will have back-ticks and fully qualified table names. So if you're using query generation features and automated re-writing of queries, backticks would make anything parsing your code less confused.

I think however, instead of mandating whether or not you can use backticks, they should have a standard for names. It solves more 'real' problems.

Kent Fredric
+2  A: 

Backticks aren't part of standard ANSI SQL. From the mysql manual:

If the ANSI_QUOTES SQL mode is enabled, it is also allowable to quote identifiers within double quotes

So if you use backticks and then decide to move away from MySQL, you have a problem (although you probably have a lot bigger problems as well)

Greg
A: 

There isn't anything wrong if you keep using MYSQL, except maybe the visual fuziness of the queries. But they do allow the use of reserved keywords or embedded spaces as table and column names. This is a no-no with most database engines and will prevent any migration at a later time.

As for easy reading, many people use caps for SQL keywords, eg.

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;
Christian Lescuyer
A: 

It's a lot easier to search your code base for something in back ticks. Say you have a table named 'event'. grep -r "event" * might return 100's of results. grep -r "`event`" * will return anything probably referencing your db. =)

EllisGL