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.
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!
I was wondering if it ok to use a question as a field name or column on a table such as IsTheWetherNiceOutsite? is there any pros or cons, or is there any other way to archive this?
If I were you I'd avoid column names with special characters like ? in the table itself. Writing queries can get troublesome.
But you can use column aliases if you want. For example,
SELECT NOW() 'What time is it?',
t.weatherNice 'Is the weather nice?'
FROM table t
It's not necessary. The is prefix already indicating that it's a boolean flag.
Prefer not to use weird characters, it might work (if use use backticks for the column name), but might not be portable, and will certainly confuse others.
Here's how I do it:
Table names are lower case, uses underscores to separate words, and are singular (e.g. foo, foo_bar, etc.
I generally (not always) have a auto increment PK. I use the following convention: tablename_id (e.g. foo_id, foo_bar_id, etc.).
When a table contains a column that is a foreign key, I just copy the column name of that key from whatever table it came from. For example, say table foo_bar has the FK foo_id (where foo_id is the PK of foo).
When defining FKs to enforce referential integrity, I use the following: tablename_fk_columnname (e.g. furthering example 3, it would be foo_bar_foo_id). Since this is a table name/column name combination, it is guaranteed to be unique within the database.
I order the columns like this: PKs, FKs, then the rest of columns alphabetically
Is there a better, more standard way to do this?
I would say that first and foremost: be consistent.
I reckon you are almost there with the conventions that you have outlined in your question. A couple of comments though:
Points 1 and 2 are good I reckon.
Point 3 - sadly this is not always possible. Think about how you would cope with a single table foo_bar that has columns foo_id and another_foo_id both of which reference the foo table foo_id column. You might want to consider how to deal with this. This is a bit of a corner case though!
Point 4 - Similar to Point 3. You may want to introduce a number at the end of the foreign key name to cater for having more than one referencing column.
Point 5 - I would avoid this. It provides you with little and will become a headache when you want to add or remove columns from a table at a later date.
Some other points are:
Index Naming Conventions
You may wish to introduce a naming convention for indexes - this will be a great help for any database metadata work that you might want to carry out. For example you might just want to call an index foo_bar_idx1 or foo_idx1 - totally up to you but worth considering.
Singular vs Plural Column Names
It might be a good idea to address the thorny issue of plural vs single in your column names as well as your table name(s). This subject often causes big debates in the DB community. I would stick with singular forms for both table names and columns. There. I've said it.
The main thing here is of course consistency!
Consistency is the key to any naming standard. As long as it's logical and consistent, you're 99% there.
The standard itself is very much personal preference - so if you like your standard, then run with it.
To answer your question outright - no, MySQL doesn't have a preferred naming convention/standard, so rolling your own is fine (and yours seems logical).
MySQL has a short description of their more or less strict rules:
https://dev.mysql.com/doc/internals/en/coding-style.html
Most common codingstyle for MySQL by Simon Holywell:
http://www.sqlstyle.guide/
See also this question:
Are there any published coding style guidelines for SQL?
Thankfully, PHP developers aren't "Camel case bigots" like some development communities I know.
Your conventions sound fine.
Just so long as they're a) simple, and b) consistent - I don't see any problems :)
PS:
Personally, I think 5) is overkill...
Simple Answer: NO
Well, at least a naming convention as such encouraged by Oracle or community, no, however, basically you have to be aware of following the rules and limits for identifiers, such as indicated in MySQL documentation: https://dev.mysql.com/doc/refman/8.0/en/identifiers.html
About the naming convention you follow, I think it is ok, just the number 5 is a little bit unnecesary, I think most visual tools for managing databases offer a option for sorting column names (I use DBeaver, and it have it), so if the purpouse is having a nice visual presentation of your table you can use this option I mention.
By personal experience, I would recommed this:
Use lower case. This almost ensures interoperability when you migrate your databases from one server to another. Sometimes the lower_case_table_names is not correctly configured and your server start throwing errors just by simply unrecognizing your camelCase or PascalCase standard (case sensitivity problem).
Short names. Simple and clear. The most easy and fast is identify your table or columns, the better. Trust me, when you make a lot of different queries in a short amount of time is better having all simple to write (and read).
Avoid prefixes. Unless you are using the same database for tables of different applications, don't use prefixes. This only add more verbosity to your queries. There are situations when this could be useful, for example, when you want to indentify primary keys and foreign keys, that usually table names are used as prefix for id columns.
Use underscores for separating words. If you still want to use more than one word for naming a table, column, etc., so use underscores for separating_the_words, this helps for legibility (your eyes and your stressed brain are going to thank you).
Be consistent. Once you have your own standard, follow it. Don´t be the person that create the rules and is the first who breaking them, that is shameful.
And what about the "Plural vs Singular" naming? Well, this is most a situation of personal preferences. In my case I try to use plural names for tables because I think a table as a collection of elements or a package containig elements, so a plural name make sense for me; and singular names for columns because I see columns as attributes that describe singularly to those table elements.
Consistency is what everyone strongly suggest, the rest is upto you as long as it works.
For beginners its easy to get carried away and we name whatever we want at that time. This make sense at that point but a headache later.
foo foobar or foo_bar is great.
We name our table straight forward as much as possible and only use underscore if they are two different words. studentregistration to student_registration
like #Zbyszek says, having a simple id is more than enough for the auto-increment. The simplier the better. Why do you need foo_id? We had the same problem early on, we named all our columns with the table prefix. like foo_id, foo_name, foo_age. We dropped the tablename now and kept only the col as short as possible.
Since we are using just an id for PK we will be using foo_bar_fk (tablename is unique, folowed by the unique PK, followed by the _fk) as foreign key. We don't add id to the col name because it is said that the name 'id' is always the PK of the given table. So we have just the tablename and the _fk at the end.
For constrains we remove all underscores and join with camelCase (tablename + Colname + Fk) foobarUsernameFk (for username_fk col). It's just a way we are following. We keep a documentation for every names structures.
When keeping the col name short, we should also keep an eye on the RESTRICTED names.
+------------------------------------+
| foobar |
+------------------------------------+
| id (PK for the current table) |
| username_fk (PK of username table) |
| location (other column) |
| tel (other column) |
+------------------------------------+
as #fabrizio-valencia said use lower case. in windows if you export mysql database (phpmyadmin) the tables name will converted to lower case and this lead to all sort of
problems.
see Are table names in MySQL case sensitive?
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.
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!