PostgreSQL has allowed me to name a column "campaign_$". I like the name because it's short and to the point, and other potential names like "campaign_receipts" seem longer and less clear.

BUT, I wonder if I'll eventually regret putting a $ symbol in a column name, either in PHP or in some other distant part of the architecture. Should I just stick to letters and underscores?


+5  A: 

You probably won't regret, but I still wouldn't recommend it.

What happens when you expand into Europe?

Also, it will look strange and confusing to new developers.

+6  A: 

Yes, you should. "campaign_receipts" is a better name.

I think campaign_receipts is far clearer than campaign_$ becasue I coudl interpret the second one in a bunch of different ways.
+1  A: 

I think it is bad practice to put special characters into a column name. Just spell out the word like campaign_money or campaign_funds and then the issue of internationalization or other possible issues become a thing of the past.

+3  A: 

There's a VERY strong convention that tables and columns are named using only letters, numbers, and (possibly) underscores, so I would consider this poor style. Beyond the i18n concerns that other posters mention, there are probably a very large number of tools that expect table and column names following this convention.

Hank Gay
The first part (convention) I agree with. The second part (i18n) I also agree with. The third part, however I don't buy. Let me rephrase it to show why. "There are a very large number of badly-written tools which don't conform to the actual language standards out there and you should write with them in mind." If SQL allows special characters in table and column names then the tools should cope or their distribution media should be stacked up and burned in fire. With the developers who made the crap tied to a stake above.
That's a great philosophy in theory, but in reality if your company/client can get significant value out of a tool then the excuse of, "They should have written it to handle are industry non-standard implementation because it's what we did was possible" doesn't help the company/client.
Tom H.
+1  A: 

It should be fine, however it may cause you more problems down the line when you want to export the data to another system, things like that.

It's good to get into the habbit of naming columns/variables etc with no special characters, as usually they are more trouble than they are worth.

Tom Gullen
+4  A: 

In addition to the other excellent reasons I'll also mention that "$" in my mind is not clear at all. Does that mean campaign expenses? Campaign savings? Campaign values?

Tom H.
+1  A: 

I wouldn't use it.

The "$" might not be valid in future databases you use (at some point you might migrate away from PostgreSQL to something else) and it also might pose problems at the application level if you do anything that maps column names to object properties if your programming language doesn't allow method names to have "$" in them.

Just my suggestion.