In a MySQL database I have large amount of tables. there is not any foreign key relationships constraint but it could be done.
In my tables the foreign key field name and its equivalent primary key field both are the same.
I can guess the relations from this, but I want to add constraint to tables according to this convention.
is there any tool to do this? or may I write a script to do?
Related
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.
Suppose I have two tables in mysql
1.Child(name,father_name)
2.Father(name,contact)
The table Father has a composite key (name,contact).Father_name in Child table references name in father . Thus a foreign key references a part of primary key.This is allowed by mysql.
However consider the following situation:
Table father has the following tuples:
(kishan,9906011111)
(kishan,9990601234)
Now suppose I insert a row in child
(xyz,kishan)
How would I know which kishan in the father table is the child xyz related to ?
This situation could have been avoided if mysql does not allow a foreign key to refer a part of the primary key .
Please answer what's the benefit of this scheme allowed by mysql ?
This is a peculiarity of MySQL. In my opinion, foreign keys should only be to unique keys or primary keys. There should not be a mapping to "sets" of values using a foreign key relationship.
Clearly, the designers of MySQL disagree (both with me and other database implementors). They allow foreign key relationships to any columns that are indexed -- in MySQL parlance, are defined as a "key". If you have a composite primary key, then the initial column(s) are such a key.
To prevent problems and make your tables unambiguous and easy to use, I would recommend:
All tables have an auto-incremented primary key.
All foreign key relationships are only to primary keys (not to unique keys or other types of key).
The primary key be named the singular of the entity followed by id (example: things would have thingId as a primary key).
The foreign key have the same name as the primary key (except when this is not possible because there are multiple foreign key relationships to the same table).
This may sound confusing and or simple but..
If I use a foreign key from Table B in Table A, which has a separate primary key. Do I need to include Table A's primary key as a foreign key in Table B?
Thanks!
========================================================================
EDIT:
Okay, let me try and clarify my question a bit.
In the case above, should I use Taco_ID as a FK in Table 2? Or is does it completely unnecessary?
In general, you don't usually make foreign keys bidirectionally like that. If you do, it means that the two tables exist in a 1-to-1 relationship: Each taco has a type, and each taco type can only be used by one taco. If you have a relationship like this, there's not really any reason to have them in separate tables, they could just be additional columns in the same table.
Normally foreign keys are used for 1-to-many or many-to-many relationships.
A 1-to-many relationship would be if many different tacos can be of the same type. They each have Taco_Type_ID foreign key.
For a many-to-many relationship, you typically use a separate relation table.
CREATE TABLE Taco_Types (
Taco_ID INT, -- FK to Table1.Taco_ID
Taco_Type_ID INT, -- FK to Table2.Taco_Type_ID
PRIMARY KEY (Taco_ID, Taco_Type_ID)
);
foreign keys and primary keys are SOMETIMES related, but not always. A foreign key in a table literally just means "whatever value is in this field MUST exist in this other table over ---> here". Whether that value is a PK or not in that other table is irrelevant - it just has to exist, and it has to be unique. That may fit the bill of being a primary key, but being primary is NOT required.
You can have composite foreign keys, e.g. in a (silly) address book, the child table you list a person's phone numbers in COULD be keyed with (firstname, lastname), but that runs into the problem of "ok, which John Smith does this number belong to?".
In most databases, foreign key references must be to primary keys or unique keys (and NULLs are allowed). MySQL recommends this but does not require it:
However, the system does not enforce a
requirement that the referenced columns be UNIQUE or be declared NOT
NULL. The handling of foreign key references to nonunique keys or keys
that contain NULL values is not well defined for operations such as
UPDATE or DELETE CASCADE. You are advised to use foreign keys that
reference only UNIQUE (including PRIMARY) and NOT NULL keys.
Do you need to reference primary keys for a foreign key relationship? First, you don't even need to declare foreign key relationships. I think they are important because they allow the database to maintain referential integrity. But, they are not required. Nor is there any semantic difference in queries, based on the presence of foreign keys (for instance, NATURAL JOIN does not use them). The optimize can make use of the declared relationship.
Second, if you are going to declare the foreign key, I would recommend using the primary key of the referenced table. That is, after all, one of the major reasons for having primary keys.
I have a Table A (with a primary Key) ID (A.ID)
A.ID needs to be the foreign key for 2 other tables, B and C.
how can I do this in PHPMyAdmin DB: i seem to only have the option to set it as the foreign key to only one other table using INNODB
If I guess right than you mixed the direction. I build a database where I could add multiple foreign key for one table. Do you use for creating the foreign key sql statments or do you add them with some kind of wizzard of phpmyadmin?
As far I remember I also had some trouble to setup that foreign keys so I used only SQL to enfoce that the keys also get those names I would like to have.
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