I have read certain places that it is a good practice to typically use an auto-incrementing Primary key for most MySQL tables, rather than simply relying on a non-increment field that will be enforced to be unique.
My question is specifically about a User table, and a table connected to it by a Foreign Key. Here's the schema:
TABLE Users {
id
name
...
}
TABLE Authors {
user_id (FK)
author_bio
}
Should the Authors table have its own auto-incrementing primary key as well, or should it rely on the user_id foreign key as a primary key?
ALSO
Are there noticeable performance reasons to NOT use the auto-incrementing id as the Primary?
It's not either-or. If you use an auto increment primary key, and you have candidate keys that need to enforce constraints, then your schema should have both.
Both your user and author tables should have individual primary keys. (Every table must have a primary key.) I would not use the foreign key as the primary key. If that truly is the case, I wouldn't have a separate author table; I'd put those columns in the user table.
PS - My naming preference is singular for tables. It should be user and author tables. They happen to contain multiple rows, but a single row means a single entity.
You most definitely want the Authors table to have its own primary key such as authors_id, and then have user_id as a foreign key.
It depends on what you're trying to accomplish. If every author maps to exactly one user (and you're sure this isn't going to change), you can get away with having user_id as a primary key. If not, you'll need an independent primary key for Authors.
(Note that the reverse relation doesn't have to be true: not every user has to map to an author.)
Related
I'm using MySQL 5.7 with WB6.3 for my study project to design the ER diagram.
When I try to create many-to-many relationship. By default MySQL will mark the primary keys of both tables as primary key in the lookup table as well.
Is it really need to have primary keys from both table as primary key in the lookup table as well ?
Please see the table car_item in my diagram below I've removed primary key from both red(idcar,iditem). Please tell me if PK is needed for them
There should be a unique key for (car_idcar, item_list_iditem_list), but it doesn't necessarily have to be the primary key. This way, you ensure that you don't create duplicate relationships between the same rows in the two tables.
A table can only have one primary key, and the car_item table already has primary key id_car_item, so the foreign keys for the relation can't also be a primary key. But there can be an arbitrary number of unique keys.
Some purists might say that if there are two unique keys (a primary key is also a unique key), one of them is redundant. In your case, the id_car_item column may not really be necessary, as it's not common to refer to relations in other tables, the relation table is just used to join the other two tables. But this isn't always the case. For instance, a user table might have a unique username column (since you don't allow multiple users to have the same name), but also a userid primary key that's used as the foreign key in other tables (this allows renaming users without having to update all the foreign keys). Some database designers like to have an auto-increment column in every table, as it's useful as a reference in user interface applications.
It is common practice to have a composite primary key in a table that implements many-to-many. This key should consist of primary keys from both tables on each side of the many-to-many relationship.
Such approach guarantees data consistency and eliminates duplication.
In your case you should define a composite primary key for table car_item that would consist of two fields { car_idcar, item_list_iditem_list }
The column id_car_item is not needed and can be dropped, it was probably added automatically, as many RDBMS add surrogate PK by default.
I have read somewhere here that having primary key in each every table is a good thing to do... Let me say I have two tables "student" and "student_details" and i am using INNODB
"student" has a few columns like - student_id(Primary Key), student_name
"student_details" has a few columns like - student_id(Foreign Key), Address, Phone, Mobile, etc..
Do "student_details" still need a primary key?
Whether you know it or not, what you are doing is column partitioning the table. You can have studentdetails.studentid be both a primary key and a foreign key. No problem with that. So, you can have a primary key in the table.
There are several reasons to do column partitioning, usually related to performance on commonly used columns or to create rows with more than the maximum number of columns. I doubt either of these apply in your case.
In fact, given the nature of the data, the studentdetails table is actually storing a "slowly-changing dimension". In simpler language, students move, so their address changes. Students change their telephone number. And so on. What you should really have is an effective and end date for each student details record. Then you can add an auto-incrementing primary key (which is what I would do) or you could declare studentdetails(studentid, effdate) as the primary key.
I have roles for users.
User can have multiple roles. I have a table called users_roles.
I have three columns - id,user,role.
id is an auto-increment column.
So,
Is it a good idea to drop the id column since I never use that in code?
If yes, then what column should be the index for this table? Or should it not have an index at all?
I agree that if user is userid then you dont need the id column, userid can be your indexed PK.
If user is the name of the user then you are going to want to keep the id, or create a user_id so that you can have a valid key to index.
users_roles is a many many link table.
There are at least 2 common approaches to primary keys on many:many tables:
users_roles has its own surrogate Primary key, as in the case here (users_roles.id)
OR, you create a composite key consisting of (user, role), since a user shouldn't be in the same role more than once.
There are many discussions on simple vs composite keys e.g. Why single primary key is better than composite keys?
Note that indexes and primary keys are different concepts. Primary Key is for uniqueness, Index is for performance. (You can have multiple indexes on a table, but only one PK)
If, as you seem to be saying, that no other tables reference user_roles, then you don't actually need a primary key.
If your users_roles table gets large, you will likely want to add an index on the users column, and possibly also the roles table, e.g. if you often search for users in a particular role.
If you are supposing to delete the "id" field then how you will make a relation between user and user_roles table.
It is always better to define a primary key. The default index is created when you define the primary key. And it somehow increases the performance.
Also when you define a foreign key the foreign Key index will also be generated. And hence your table query execution will become faster.
This is your first answer:
According to your requirements, for the current time being you can delete the "id" primary key from user_roles table as it is just use as a relationship table between users and roles.
But in most of PHP frameworks, this is not a good practice to drop a primary key even in relationship table.
This is your second answer: If you would drop a primary key, then you will have to maintain the indexes on "user" and "role" field as a foreignKey index. And if you are not going to drop a primary key from user_roles table. Then 3 indexes would be generated for "id", "user" and "role" fields. First index will be the primary index and rest two are foreignKey index.
Explicitly defining of more indexes on a table also causes some extra overhead on query execution.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
mySQL's KEY keyword?
Like
PRIMARY KEY (ID),
KEY name (name),
KEY desc (desc),
etc.
what are they useful for?
Keys are used to enforce referential integrity in your database.
A primary key is, as its name suggests, the primary identification of a given row in your table. That is, each row's primary key will uniquely identify that row.
A unique key is a key that enforces uniqueness on that set of columns. It is similar to a primary key in that it will also uniquely identify a row in a table. However, there is the added benefit of allowing NULL in some of those combinations. There can only be 1 primary key, but you can have many unique keys.
A foreign key is used to enforce a relationship between 2 tables (think parent/child table). That way, a child table can not have a value of X in its parent column unless X actually appears in the parent table. This prevents orphaned records from appearing.
The primary key constraint ensures that the column(s) are:
not null
unique (unique sets if more than one column)
KEY is MySQL's terminology in CREATE TABLE statements for an index. Indexes are not ANSI currently, but all databases use indexes to speed up data retrieval (at the cost of insertion/update/deletion, because of maintenance to keep the index relevant).
There are other key constraints:
unique
foreign key (for referential integrity)
...but your question doesn't include examples of them.
keys are also called indexes. They are used for speeding up queries. Additionally keys can be constrains (unique key and foreign key). The primary key is also unique key and it identifies the records. The record can have other unique keys as well, that do not allow to duplicate a value in a given column. Foreign key enforces referential integrity (#Derek Kromm already wrote excellent description). The ordinary key is used only for speeding up queries. You need to index the columns used in the WHERE clause of the queries. If you have no index on the column, MySQL will need to read the whole table to find the records you need. When index is used, MySQL reads only the index (which is usually a B+ tree) and then read only those record from the table it found in the index.
Primary KEY is for creating unique/not null constraint for each row in the table. Also searching by this key is the fastest. You can create only one PK in the table.
Ordinary key/index is key for speeding your searching by this column, sorting, grouping and joining with other table by this key.
Indexes drawback:
Adding new indexes to table will influence on speed or running insert/update/delete statements. So you should select columns for indexing in your table very carefully.
Key are used for relation purposes between tables and you are able to create joins in order to select data from multiple tables
What, you didn't fine the wikipedia entry comprehensive? ;-)
So, a key, in a relational database (such as MySQL, PostgreSQL, Oracle, etc) is a data constraint on a column or set of columns. The most common keys are the Primary key and foreign keys and unique keys.
A foreign key specifically relates the data of one table to data in another table. You might see that a table blog_posts has a foreign key to users based on a user_id column. This means that every user_id in blog_posts will have a corresponding entry in the users column (this is a one-to-many relationship -- a topic for another time).
If a column (or group of columns) has a unique key, that means that there can only be one such incidence of the key in the table. Often you'll see things like email addresses be unique keys -- you only want one email address per user. I've also seen a combination of columns match to a unique key -- the five columns, first_name, last_name, address, city, and state, will often be a unique key -- realistically, there can only be one William Gates at 1835 73rd Ave NE, Medina, Washington. (I do realize that it is possible for a William Gates Jr. to be born, but the designers of that database didn't really care).
The primary key is the primary, unique identifier of a given table. By definition it is a unique key. It is something which cannot be null and must be unique. It holds a special place of prominence among the indexes of a given table.
Does a Join table (association table) have a primary key ? many to many relationship. I've seen some Join tables with a primary key and some without can someone please explain when you would have a primary key in a join table and why?
Thank you in advance;-)
In a pure 'join' or junction table all the fields will be part of the primary key. For example let's consider the following tables:
CREATE TABLE USERS
(ID_USER NUMBER PRIMARY KEY,
FIRST_NAME VARCHAR2(32),
LAST_NAME VARCHAR2(32));
CREATE TABLE ATTRIBUTES
(ID_ATTRIBUTE NUMBER PRIMARY KEY,
ATTRIBUTE_NAME VARCHAR2(64));
A junction table between these to allow many users to have many attributes would be
CREATE TABLE USER_ATTRIBUTES
(ID_USER NUMBER REFERENCES USERS(ID_USER),
ID_ATTRIBUTE NUMBER REFERENCES ATTRIBUTES(ID_ATTRIBUTE),
PRIMARY KEY(ID_USER, ID_ATTRIBUTE));
Sometimes you'll find the need to add a non-primary column to a junction table but I find this is relatively rare.
Share and enjoy.
All tables should have a primary key. :-)
You can either use a compound foreign key, or a blind integer key.
You would use the compound foreign key when there are no other elements in your association table.
You could use the blind integer key when the association table has elements of its own. The compound foreign key would be defined with two additional indexes.
It depends on the records you are associating. You can create a composite primary key on the id's of the associated records as long as you don't need multiple records per association.
However, its far more important that you make sure both these columns are indexed and have referential integrity defined.
Relationship tables frequently have three candidate keys, one of which need not be enforced with a constraint, and the choice of which key (if any) should be 'primary' is arbitrary.
Consider this example from Joe Celko:
CREATE TABLE Couples
(boy_name INTEGER NOT NULL UNIQUE -- nested key
REFERENCES Boys (boy_name),
girl_name INTEGER NOT NULL UNIQUE -- nested key,
REFERENCES Girls(girl_name),
PRIMARY KEY(boy_name, girl_name)); -- compound key
The "Couples" table lets you insert
these rows from the original set:
('Joe Celko', 'Brooke Shields')
('Alec Baldwin', 'Kim Bassinger')
Think about this table for a minute.
The PRIMARY KEY is now redundant. If
each boy appears only once in the
table and each girl appears only once
in the table, then each (boy_name,
girl_name) pair can appear only once.
From a theoretical viewpoint, I could
drop the compound key and make either
boy_name or girl_name the new primary
key, or I could just leave them as
candidate keys.
SQL products and theory do not always
match. Many products make the
assumption that the PRIMARY KEY is in
some way special in the data model and
will be the way to access the table
most of the time.
...HOWEVER I suspect you question is implying something more like, "Assuming I'm the kind of person who shuns natural keys in favour of artificial identifiers, should I add an artificial identifier to a table that is composed entirely of artificial identifiers referenced from other tables?"