In MySQL, is it necessary to surround tablenames with the tickmark? I've often seen code snippets that use the tickmarks, but I've not encountered a case where not surrounding a tablename with the tickmarks does anything different than with.
It looks like the framework I work with automatically parses reserved word keynames with tickmarks.
The tickmarks are there to distinguish the table (or column!) names from SQL reserved words. For example, without the tickmarks, a table or column named update could clash with the SQL command update.
It's best practice not to name tables and columns with reserved words in the first place, of course, but if you port an application to a new database engine (or possibly even a new MySQL version), it might have a different set of reserved words, so you may have just broken your app anyway. The tickmarks are your insurance against this sort of oops.
Tickmarks are necessary when table or column names use mySQL keywords.
I once worked at a job where they had a database of "locations". They called it states. and had everything in tables each table was named by state code. so Missouri was MO, and Arkansas was AR.
Several state codes are also reserve words OR ( Oregon), and IN (Indiana), and ON (Ontario) ... I know not exactly a state.
Even tho I think there were better ways of organizing their database data, there are cases where people want to name things a reserved word. This is an example where the `` marks kept code working.
It's only necessary if your table name is composed of non-"word" characters (ie: anything besides letters, numbers, and underscores), or happens to be the same as a keyword in MySQL. It's never "bad" to quote the name, but it's bad not to when you have to, so many programs that generate MySQL queries will be conservative and quote the name -- it's just easier that way.
Related
May be this question has been answered before but I couldn't find it.
I am using a 2/3 yr old MySQL database which has hyphens in its column names. When I try to use these names from my Java code, the names are broken at the hyphen (e.g. air_port becomes air) and thus are not found. I tried replacing hyphens to underscores in my code hoping that the DB might treat them equally but that doesn't work.
How can I escape the hyphen or how can I access these columns ? Could this be an issue of the character set being used ?
enclose the names within `back-ticks`
Do you have hyphens (-) or underscores (_) in your column names?
Hyphens are a big problem because if you end up mapping a column name to a variable, most languages do not like to have hyphens inside variable names. Perhaps you are using one of the Java libraries that automatically generates variables or objects whose names are based on column names.
Depending on the nature of your problem, there are a couple of different approaches you can use:
Rename all of your columns using ALTER TABLE. Be conscious that this could affect referential integrity or other applications that depend on the database. If you don't know what that means, don't do it.
Create SQL views that simple restate the tables you need but with "better" column names. This is not very efficient, but it will allow you to get what you want.
Use the AS keyword when running your SELECT statements to rename columns within queries.
None of these are great solutions, but they should get you started. Good luck!
It's better to not use hyphens in your column names. I suffered a big problem with JOIN statements where hyphens caused big trouble - there even escaping names in back ticks didn't work.
Convert the column names to use underscores - this is the safest way to go.
As an alternative - in case where even backticks should cause problems (you know it happend to me) and you want to stick to hypens no matter what - just create a VIEW to reflect the same table with all the fields and query the view instead of the original table.
Hyphens in database names aren't good also. But you can use them with the backtick trick `
`name-with-hyphen`
This entry at the MySQL forum suggests that you might have a problem. However, I think it's referring to data and not column names.
This says "don't do it." Don't know how authoritative it is.
I had to create a db named pre-ca_db.
I solved the problem with
create database `pre-ca_db`;
Good luck!
One common issue I run into when naming columns in a new database table is the right name to use for classifying subtypes. The most natural column name is typically type, but I try to avoid using SQL keywords or reserved words in my naming.
I'm aware that type is a non-reserved keyword in both MySQL and Postgres, so I can use it, but should I?
What is current best practice around using type as a column name? Is there a synonym which is so broadly equivalent that it just makes sense to use that?
Over the years I've spent way to much time trying to pick other names and this has come up twice in discussions in the past week, so I wanted to see if there is any clear consensus around this?
In case it helps anyone else, some alternatives I've used in the past to try to get around this include:
category
kind
subtype
type_of
role
class
<entity>_type
my suggestion is usually to avoid using keywords but not because they're reserved but because they're often actually ambiguous in and of themselves.
For example, say you have a customer table - with a column 'type' this might be filled with segmentation (high value/low value etc) or it could be filled with source (direct marketing/walk in etc).
"Type" is a low-value word. I'd usually recommend being as explicit as possible at the expense of column-length. For example 'CustomerSourceType' or 'InventoryLocationType' or whatever is actually clearer in the scenario.
Trailing underscore
The SQL standard explicitly promises to never use a tailing underscore on any keyword, reserved word, etc.
So if you name your identifiers (table names, column names, index names, etc.) with a trailing underscore, you need never worry about a collision.
CREATE TABLE product_ (
name_ VARCHAR ,
type_ VARCHAR ,
…
);
The advice others gave to “avoid using reserved words” is naïve, is likely to fail, and is not portable. Many years ago I did a quick survey of various database products and their keywords. I collected a distinct list of about a thousand. Really. You would not believe how many non-obvious words are used in various ways by various products. Of course, collisions are context-dependent, so not all reserved words will be a problem if used by you in particular ways. But the trailing underscore trick relieves you of the need to study each product’s list of reserved words and monitor your codebase for potential collisions.
Naming is tricky. Of course you should make an effort to use the most clearly descriptive name possible. Sometimes, especially in a particular problem domain, a word like “type” might be appropriate. If so, add the trailing underscore (type_) and sleep well.
First rule,
Never ever ever ever use Keywords or Reserver words. The person coming after you will suffer.
If you are only using 'Type' for this time. You could use Types
Naming a column "type" is technically fine it seems. I name my columns to avoid confusion with methods / keywords in the language / frameworks I might use to query to database.
Also, what if I add a new language or framework that interfaces with the DB.
"type" is a method name or keyword in many languages.
Perhaps for no good reason (it does take away some awesome column names). Shouldn't be that big a deal either way. Just a personal preference.
We have a legacy schema file which has the following column names, would like to understand if any of them would cause an issue if we port our application to h2, mysql, postgres or oracle.
e.g how would I know if using this would be ok across the databases listed below. Are there any good tools which can do a preliminary check on this?
key
when
size
type
count
from
with
Should be quite easy to get the list of reserved words and build a table of the reserved words. Here are some lists of reserved words:
Oracle: http://download.oracle.com/docs/cd/B19306_01/em.102/b40103/app_oracle_reserved_words.htm
SQL Server:
http://msdn.microsoft.com/en-us/library/ms189822.aspx
PostgreSQL:
http://www.postgresql.org/docs/current/static/sql-keywords-appendix.html
MySQL:
https://dev.mysql.com/doc/refman/5.6/en/keywords.html#keywords-in-current-series
And here's an online checker: http://www.petefreitag.com/tools/sql_reserved_words_checker/?word=on
I am not aware of any tables but it should not be difficult to filter them if you have the list of table names and column names.
Oracle has a V$RESERVED_WORDS view in its data dictionary.
All you have to do is to match your table/column names against this: Just add them to temp table and join with tis view. If you have a result for your query then you have a reserved word.
Other databases may have such metadata as well.
DatabaseMetaData.getSQLKeywords() is supposed to return a comma-separated list of reserved words within this database. This list doesn't contain ANSI SQL keywords such as FROM however. I'm not completely sure if this really contains all keywords in all databases however.
For H2, the list of keywords is documented under Keywords / Reserved Words.
The easiest way to find out would be to try it. All of the database management systems you mention are open source or free to download and try. Run your SQL script with the CREATE TABLE statements through them and see what happens.
The problem with asking this without reference to an actual SQL script is that some parsers have various classes of reserved words. Some key words might be listed as key words, but might still be OK to use as column names, but perhaps not in tricky SELECT statement later on. So it's always best to try it out.
I suggest based on the list you give, it won't work in most SQL systems. But you can always consistently double quote the identifiers to steer clear of key word problems. (You will need to run MySQL in ANSI mode, though.)
Do underscores in table names affect performance or cause issues on some platforms?
For example, user_profiles
Would it be better to use userProfiles or is it just a matter of personal preference?
Nope. Underscores are perfectly legal in table names.
This page here in the MySQL documentation tells you about what characters are allowed.
Basically:
Permitted characters in unquoted identifiers:
ASCII: [0-9,a-z,A-Z$_]
Extended: U+0080 .. U+FFFF
Permitted characters in quoted identifiers:
ASCII: U+0001 .. U+007F
Extended: U+0080 .. U+FFFF
Personally I tend to stick with lowercase a-z, the occasional number, and underscores.
But as #Vince said, it's just personal preference.
The only issue I've seen is that when using mysqlshow to view the structure of a table it appears to treat the underscore as a wildcard and returns only matching table names if there is an underscore in the name.
I could find no way to view the table structure of a table if there is an underscore in the name. I just discovered and confirmed this myself this morning.
I know this to be true of MySQL versions 4.0.18 and 4.1.22 for older versions and 5.1.52 for newer. Perhaps this is documented somewhere (I haven't taken the time to look yet), but it might be a perplexing thing for others, so I decided to mention it when I ran across this question when looking for information on the problem myself.
There's nothing wrong with using underscores, but keep in mind there may be occassions you need to escape the underscore, e.g. My\_Table
I found a few links to MySQL bugs that have either been marked closed or can't reproduce regarding underscores. As far as I know there are no issues - I always use underscores over camel-case and haven't experienced any problems.
No, it's perfectly good. In fact, it is the most recommended naming from MySQL (based on who they name their internal tables!).
Be aware that naming that in Microsoft Windows the default MySQL behaviour is to lower-case your table names. This may cause problems. I am not sure what causes this.
However I personally prefer to name my tables like UserLikesPage, User and PostComment for example, since it reflects the class name in my code and I don't use Windows with MySQL.
You should avoid it. Although it is a permitted character in MySQL documentation, it appears it might cause trouble. For example, in MySQL 5.0 & 5.1 (and may be later versions), the query cache is never hit for queries involving a table name containing an underscore.
Nope, underscores in a database never cause any issues at all.
My experience say that it is a better idea to identify any words in a database column.
If we use 'thisIsMyColumn' as a column name it's easy to write them,
but 'this_is_my_column' as column name is more readable than the previous one.
There is no problem using underscores. I think it is just personal preference.
Many database visualization tools such as SQuirreL SQL and DbVisualizer also treat the underscore as a wildcard of sorts, grouping tables "matching" into a tree. For example, a table "document_a" and related tables "document_a_details", "document_a_history". In DbVisualizer, looking at the "document_a" table shows columns for all three tables.
This is generally not a problem, but can be confusing. For example, using SQuirreL SQL's graphing tools to generate ERDs combines columns from multiple tables into a single table and draws connectors for the relationships of all of these columns in the ERD. This results in relationships being drawn that don't actually exist.
For this reason, I would not include underscores in table names.
I never had issues with underscore when naming my tables. It's just personal preference.
You can simply add grave accent (`) before and after column name. For example:
CREATE TABLE USERS(
`PERSON_ID` NVARCHAR(100),
`FNAME` NVARCHAR(255),
`LNAME` NVARCHAR(255),
PRIMARY KEY (`PERSON_ID`)
);
May be this question has been answered before but I couldn't find it.
I am using a 2/3 yr old MySQL database which has hyphens in its column names. When I try to use these names from my Java code, the names are broken at the hyphen (e.g. air_port becomes air) and thus are not found. I tried replacing hyphens to underscores in my code hoping that the DB might treat them equally but that doesn't work.
How can I escape the hyphen or how can I access these columns ? Could this be an issue of the character set being used ?
enclose the names within `back-ticks`
Do you have hyphens (-) or underscores (_) in your column names?
Hyphens are a big problem because if you end up mapping a column name to a variable, most languages do not like to have hyphens inside variable names. Perhaps you are using one of the Java libraries that automatically generates variables or objects whose names are based on column names.
Depending on the nature of your problem, there are a couple of different approaches you can use:
Rename all of your columns using ALTER TABLE. Be conscious that this could affect referential integrity or other applications that depend on the database. If you don't know what that means, don't do it.
Create SQL views that simple restate the tables you need but with "better" column names. This is not very efficient, but it will allow you to get what you want.
Use the AS keyword when running your SELECT statements to rename columns within queries.
None of these are great solutions, but they should get you started. Good luck!
It's better to not use hyphens in your column names. I suffered a big problem with JOIN statements where hyphens caused big trouble - there even escaping names in back ticks didn't work.
Convert the column names to use underscores - this is the safest way to go.
As an alternative - in case where even backticks should cause problems (you know it happend to me) and you want to stick to hypens no matter what - just create a VIEW to reflect the same table with all the fields and query the view instead of the original table.
Hyphens in database names aren't good also. But you can use them with the backtick trick `
`name-with-hyphen`
This entry at the MySQL forum suggests that you might have a problem. However, I think it's referring to data and not column names.
This says "don't do it." Don't know how authoritative it is.
I had to create a db named pre-ca_db.
I solved the problem with
create database `pre-ca_db`;
Good luck!