This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Primary key/foreign Key naming convention
What is the naming convention for Primary Key column in Db Tables?
For instance:
PK_Country or CountryId or ID or PrimaryKey or.. ?
I like the Ruby on Rails conventions:
primary key in any table is auto-increment integer column called id
foreign keys are named as foreign table name plus _id. Example:
country_id is a foreign key that corresponds to a record from the countries table
Columns should be named based on the data elements that they represent, not based on what constraints apply to them. A primary key column should be named in the same way you name any other column. The ISO 11179 standard has some useful guidelines for naming data elements.
If the table is called Test I would call the PK column TestID.
That is pretty much up to the designer of the db. When I do it I make the field name of the primary key: id and field name of foreign keys: tablenameId
I always try to start primary keys with PK and foriegn keys with FK. Also, when naming foriegn keys, I try to include the table names and column names in the name of the foriegn key: FK_Questions-test-id_Tests-seq-num would be a foriegn key from table questions to table tests where questinos.test_id = tests.seq_num. i think it helps to name them that way for when you are glancing at your keys.
There really is not a defined standard; rather, you should develop your own convention and make sure that every primary key you define is consistent with that convention.
Related
I'm trying to understand something about the foreign key of a database.
I couldn't find a clear answer for this.
The definition of a foreign key goes something like this,
"Foreign key is a field or a group of fields in a table that refers to the primary key of another table"
OK I get that.
Then we learn about types of relationships we can have among tables using foreign keys.
In one-to-many(1:M) and many-to-many(M:N) relationships, there are duplicates in the foreign key.
But how can this be?
If a foreign key refers to a primary key and a primary key can't have duplicates, how can a foreign key can?
I'm confused.
Can someone please explain this to me?
Note - I'm expecting a common answer, not a DBMS specific one.
For example:
There is an employee table with a primary key column called EmployeeID. There is also a foreign key called SupervisorID, which references a different row in the same table.
Two employees work for the same supervisor. They will have different values in the EmployeeID field, but the same value in the SupervisorID field.
This example uses a reference back to the same table, but the concept is the same when the foreign key references a different table.
What is the difference between Primary and Unique key (in MySQL)? How these can be considered as a foreign key? please explain.
I tried creating a database table and don't know how to make a primary key as a foreign key. Does it take Joins concept where the separating attribute automatically create a foreign key?
A table in MySQL can only have one Primary Key at most, while you can create as many unique Keys or indexes as you want.
Also a primary key is not nullable while a unique key can have NULL as value.
But the biggest difference is the purpose:
You want to have a primary key because you need an identifier
The unique Key/Index on the other hand is usefull to controll values that are automatically getting inserted into your table (e.g. to avoid duplicates where none are allowed)
If you want to use a column as a forgein key, you need to define it as a primary key first. Unique Constraint can not be related with other tables as a foreign key.
I am currently creating a database using SQL but I have found the need to use a foreign key to in 3 different fields in a single table.
I have CourseID1, CourseID2 and CourseID3 in students courses table. Each of those 3 fields need to be foreign and reference to the CourseID field in the course table which is a primary key.
Is this possible? how do I go about doing this?
Thank you
This is possible. You would do:
foreign key (CourseId1) references Courses(CourseId),
foreign key (CourseId2) references Courses(CourseId),
foreign key (CourseId3) references Courses(CourseId),
That said, you don't want to do this. Having multiple columns with numeric appendages usually means that you want an association/junction table. In this case, you want a table named something like StudentCourses which would have one row per student and per course that the student takes.
should I signal the foreign key in a database column name?
FKOrder vs. FK_Order vs. Order
The short answer is no - don't put "FK" in column names of foreign key columns. You can still signal the intent of the column though, here's how I do it:
Naming foreign key columns
It depends on your naming convention for the target of the FK. If you have Id, then I'd prepend the table name when creating FK columns.
Example 1:
For table User with PK Id and table Workitem with user ID FK, I'd call the column Workitem.UserId.
If there were more than one FK between the same tables, I'd make this clear in the column name:
Example 2:
For table User with PK Id and table Workitem with "assigned to user ID" and "created by user ID" FKs, I'd call the columns Workitem.CreatedByUserId and Workitem.AssignedToUserId.
If your naming convention for PKs is more like UserId, then you'd factor that into the above examples so as not to end up with UserUserId.
Naming foreign key constraints
This is mine:
FK_childtablename_[differentiator]parenttablename
The differentiator is used when there is more than one FK between the same two tables (e.g. CreatedByUserId and AssignedToUserId). Often I use the child table's column name for this.
Example 1:
Given tables: Workitem and User
Where User has CreatedByUserId and AssignedToUserId
Foreign key names are FK_Workitem_User_CreatedByUser and FK_Workitem_AssignedToUser
I use double-underscores if tables/columns have underscores in the name:
Example 2:
Given tables: work_item and user
Where user has created_by_user_id and assigned_to_user_id
Foreign key names are FK_work_item__created_by_user and FK_work_item__assigned_to_user
Is usual to name the foreign key fields with an ID (IDORDER, IDPERSON, ...), if you have a table called PERSONS and another CITIES, if one person is in certain city, CITIES has an IDCITY field (K), PERSONS has a IDPERSON (K), and other field IDCITY (FK).
Hope this answers your question. I mean, a foreign key is only foreign when it's in other table, but not in theirs. But it's a good practice to name always the same to the same fields, even if they are in other tables, as a foreign key.
You shouldn't.
If a column becomes a foreign key later, you will have to change the column name, breaking all the scripts that are using it.
If there are multiple foreign keys, you don't know which column belongs to which key, so the only information you gain is that the column is a foreign key, but you already know it by looking at the keys.
Usually I name the foreign key column the same as the primary key, so I know immediately where the key maps.
I normally use the same name as the referenced column in the table holding the FK.
Only if this is potentially confusing (or a column with this name already exists, say id), would I be more explicit. In such a case, adding the entity type name before the rest - say ProductId.
My style is slightly different:
fk_table_column
eg: fk_user_id that is foreign key to User table on id column. I do not use any capital latter.
Say I have this table:
Person table
--------------
PersonId
Address table
------------
AddressId
PersonAddressId
where PersonAddressId is PersonId and the foreign key. Is there any type of database violation in renaming the foreign key? It can become very confusing to work with when they have different names.
It's generally helpful to name the foreign key column the same as the primary key column it references, where possible.
Of course, sometimes it's not possible:
Two columns in Address might both be foreign keys to Person, so obviously you can't name both columns PersonId.
Some tables contain a foreign key to itself, e.g. Employee.manager_id could be a reference to Employee.employee_id. Again, you can't name the column the same as the referenced primary key in this scenario.
There are no strict naming conventions in SQL. One source for suggested metadata naming conventions is ISO 11179.
Agreed and that's why the convention is to name PersonAddressId as PersonId.