Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables
table_2231and your columns
column_4231(in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If it's a news website, it's very likely you'll have a table called
articles, or if you have some subscription service you'll have tables
users, and so on. Also, if your server is compromised, an attacker will figure out the table names almost immediately.
On the other hand, if there's a way around it, there's no need to disclose it. If your security is taken care of, a layer of obscurity wouldn't hurt in that case. In fact, a layer of obscurity on top of good security measures is often a good thing.
However, I'm afraid you're trying to do something like this
SELECT * FROM $UNTRUSTED_INPUT WHERE blah = 1
In that case, absolutely not. Don't do it.
Exposing table names might have broader consequences than you expect. For instance, you could be putting your company at legal disadvantage by disclosing a table names like
single_female_users etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much.
You cannot always control that of course. A hacker can expose your table names as well. So the best practice would be creating tables like they will be public tomorrow but refraining from giving the information away.
More information you expose more vulnerable you are, no matter of his priority in your security policies.
You can segment your tables into sensitive and general. Sensitive tables should not be "Exposed" but "Aliased". In the long run however, your solution is only as secure as the value it holds for the person interested in getting in.