Tell me please either should I to give name the foreign key?
CONSTRAINT constraint_name
FOREIGN KEY foreign_key_name (columns)
REFERENCES parent_table(columns)
ON DELETE action
ON UPDATE action
I can do some manipulations with the constraint by it's name, but what I can do with the foreign key name? Give me some examples please.
As the documentation explains:
MySQL requires indexes on foreign keys and referenced keys so that
foreign key checks can be fast and not require a table scan. In the
referencing table, there must be an index where the foreign key
columns are listed as the first columns in the same order. Such an
index is created on the referencing table automatically if it does not
exist. This index might be silently dropped later, if you create
another index that can be used to enforce the foreign key constraint.
index_name, if given, is used as described previously.
In other words, what you are providing is not a "foreign key name" but a "(foreign key) index name".
Having a name for an index is useful for tracking that index.
To be honest, though, I don't provide such names. I would much rather explicitly declare an index on the foreign keys, rather than have the database do it for me.
(Note: Most databases do not automatically create an index when a foreign key is declared.)
Yes it is.
If you want to alter or drop constraint in future,then it is possible using name only.
DROP FOREIGN KEY constraint_name;
You can check here.
Related
Is the following add index code redundant after adding the FK?
ALTER TABLE main ADD FOREIGN KEY (language_id) REFERENCES main_language (id);
ALTER TABLE main ADD INDEX (language_id);
Why or why not?
Yes, it is redundant. Adding the FOREIGN KEY constraint implicitly creates an index on language_id. If you needed to add a different composite index which incorporated other columns, it would not be redundant but the single column is.
ALTER TABLE main ADD FOREIGN KEY (language_id) REFERENCES main_language (id);
-- This is redundant
ALTER TABLE main ADD INDEX (language_id);
-- This is not redundant
ALTER TABLE main ADD INDEX (other_column, language_id);
According to MySQL docs, MySQL will not create a new index on the FOREIGN KEY column if one is already present at the time the FOREIGN KEY is created.
MySQL requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan. In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist. This index might be silently dropped later, if you create another index that can be used to enforce the foreign key constraint. index_name, if given, is used as described previously.
So because the indexed columns are used left-to-right, if you already had this index on the column, creating the FOREIGN KEY constraint would not need to create a new index.
-- Already has a composite index with the FK column listed first
ALTER TABLE main ADD INDEX (language_id, other_column);
-- This won't create a new index when the constraint is defined
ALTER TABLE main ADD FOREIGN KEY (language_id) REFERENCES main_language (id);
Edit:
According to this note in the above paragraph:
This index might be silently dropped later, if you create another index that can be used to enforce the foreign key constraint
...the docs seem to imply that if you created your proposed redundant index, MySQL may silently drop the index it created implicitly as part of the FORIEGN KEY constraint since the explicitly created one can be used instead. So it may not continue to maintain both indices.
Likewise, this suggests that adding the composite index above could result in MySQL no longer needing to maintain the FK's implictly created index.
ALTER TABLE main ADD FOREIGN KEY (language_id) REFERENCES main_language (id);
-- Adding this later may allow MySQL to drop the implicit index created with the FK
ALTER TABLE main ADD INDEX (language_id, other_column);
I have a database with two tables, PROCESS (PK Process_Id) and PROCESS_STAGE (PK Stage_Id, FK Process_Id).
At least I think I have set this up - in the foreign key relationships dialogue box I have
Foreign key base table: PROCESS_STAGE,
Foreign key columns: Process_Id,
Primary/unique key base table: PROCESS,
Primary/unique key column: Process_Id.
I have also set enforce for replication and enforce foreign key constraints to 'Yes'.
But I can still do the following things which break this relationship:
Delete items from PROCESS which have references from
PROCESS_STAGE
What do I need to do to correct this?
Thanks!
Try using SQL to create the foreign key
ALTER TABLE PROCESS_STAGE WITH CHECK ADD
CONSTRAINT FK_PROCESSTAGE_PROCESS
FOREIGN KEY (Process_Id) REFERENCES PROCESS (Process_Id)
If this still fails, look at the tables schema/owner: you may have more than one table and you're using the wrong one. Example:
dbo.PROCESS_STAGE
deed02392.PROCESS_STAGE
Navicat does not show primary keys which are also foreign key on table report as foreign keys. Why?
I gave the image explaining the situation:
A foreign key is a constraint that applies only to the referencing table. In your case, the translate_talent_id field has a foreign key constraint that references another field of another table.
On the other hand, translator_id is probably referenced by foreign keys in other tables. However, such foreign keys won't appear (or have any effect) on the the referenced table (trl_translator in this case). That is why your MySQL client is not showing any foreign keys on translator_id.
Does MySQL index foreign key columns automatically?
Yes, but only on innodb. Innodb is currently the only shipped table format that has foreign keys implemented.
Apparently an index is created automatically as specified in the link robert has posted.
InnoDB requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan. In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist. (This is in contrast to some older versions, in which indexes had to be created explicitly or the creation of foreign key constraints would fail.) index_name, if given, is used as described previously.
InnoDB and FOREIGN KEY Constraints
For those who are looking for quote from 5.7 docs:
MySQL requires indexes on foreign keys and referenced keys so that
foreign key checks can be fast and not require a table scan. In the
referencing table, there must be an index where the foreign key
columns are listed as the first columns in the same order. Such an
index is created on the referencing table automatically if it does not
exist. This index might be silently dropped later, if you create
another index that can be used to enforce the foreign key constraint.
index_name, if given, is used as described previously.
You don't get the index automatically if you do an ALTER TABLE (instead of CREATE TABLE), at least according to the docs (the link is for 5.1 but it's the same for 5.5):
[...] When you add a foreign key constraint to a table using ALTER TABLE, remember to create the required indexes first.
As stated it does for InnoDB. At first I thought it was strange that many other (in particular MS SQL and DB2) doesn't. TableSpace scans are only better than index scans when there are very few table rows - so for the vast majority of cases a foreign key would want to be indexed. Then it kind of hit me - this doesn't necessarily mean it has to be a stand alone (one column) index - where it is in MySQL's automatic FK Index. So, may be that is the reason MS SQL, DB2 (Oracle I'm not sure on) etc leave it up to the DBA; after all multiple indexes on large tables can cause issues with performance and space.
Yes, Innodb provide this. You can put a foreign key name after FOREIGN KEY clause or leave it to let MySQL to create a name for you. MySQL automatically creates an index with the foreign_key_name name.
CONSTRAINT constraint_name
FOREIGN KEY foreign_key_name (columns)
REFERENCES parent_table(columns)
ON DELETE action
ON UPDATE action
It's not possible to get index key automatically use
ALTER TABLE (NAME OF THE TABLE) ADD INDEX (FOREIGN KEY)
Name of the table which you have created for example photographs and FOREIGN KEY for example photograph_id. The code should be like this
ALTER TABLE photographs ADD INDEX (photograph_id);
In my table I have a foreign key which is also a unique key.
How can I remove the unique Key without removing the foreign key?
When I do :
ALTER TABLE affaire DROP KEY contact_client_id;
I am getting a : ERROR 1553 (HY000): Cannot drop index 'contact_client_id': needed in a foreign key constraint
I don't think that this is possible because foreign keys must be on indexes.
MySQL requires indexes on foreign keys and referenced keys so that
foreign key checks can be fast and not require a table scan. In the
referencing table, there must be an index where the foreign key
columns are listed as the first columns in the same order. Such an
index is created on the referencing table automatically if it does not
exist. This index might be silently dropped later, if you create
another index that can be used to enforce the foreign key constraint.
index_name, if given, is used as described previously.