Hi I have a situation like shown below:
Here, I have two main tables A & B. with Primary Keys IdA and IdB.
Now I have a table C, where primary key is IdC, and colum IdB is actually a foreign reference to Table B (Id) with Cascade option.
Similarly, I have Table D with only two colums and both are references to table A and Table C.
So that IdA in D is referencing Id in Table A and IdC in table D is referencing IdC in Table C.
It works fine, such that if i delete an entry in Table C, it gets deleted from Table D.
Also if i delete an entry in Table A, it also gets deleted in Table D.
However what is not working, I can not delete an entry in Table D.
Atleast phpmyadmin does not allow me to do that. How can i do that. Because if i delete an entry in Table D. i don't wnat any other table to be affected by it. Any suggestions?
Okay so it was a very trivial issue, Table D did not have any primary key colum. After adding that, now i get the option to be able to delete any row i like
Related
I try to do this into mysql :
Create a first table with A, B, C columns and a composite primary key on A and B.
Create a second table A, B, D, E columns with A, B, D as primary key and of course A, B referenced as a foreign from first table.
I use mysql workbench to creates columns, add keys and foreigns constraints, but when i try to apply i receive this error :
ERROR 1215: Cannot add foreign key constraint
The thing is that i don't know what exactly is wrong with my design.
Can you help me.
Your problem is that you have (A, B) pairs in the second table which do not have matches in your first table.
Run this:
select secondTable.A, secondTable.B
from secondTable
where not exists (select 1
from firstTable
where firstTable.A = secondTable.A and firstTable.B = secondTable.B);
With this query you will find A, B values in secondTable which do not match any records in firstTable.
To be able to create your foreign key, you will need to either remove those records from secondTable or insert their matches into firstTable.
I'm using MySQL & I need to create following tables.
1st table : having 3 attributes A,B,C
2nd table : having 2 attributes B,D
3rd table : having 2 attributes C,E
Now, A is the primary key.
I need to create the 2nd-3rd tables, such that the values in B for 2nd table should be already present in 1st table's B attribute, & similarly values in C of 3rd table should be already present in C of 1st table.
My attempts :
1) put A in both, 2nd & 3rd tables, & keep them as foreign key referencing A of 1st table, & put on update cascade in each.
2) keep check constraints for both 2nd & 3rd tables, although I couldnt find proper syntax for the check constraints when attributes are from different tables.
Pl suggest better options or improvise the current approaches I've thought of.
such that the values in B for 2nd table should be already present in 1st table's B attribute , & similarly values in C of 3rd table should be already present in C of 1st table.
In order to satisfy the first requirement, B must be declared as unique in the first table. To satisfy the second requirement, C must be unique in the first table. Thus, we would get a structure of (the choice of data type is arbitrary):
Create Table FirstTable
(
A varchar(50) not null Primary Key
, B varchar(50) Unique
, C varchar(50) Unique
);
Create Table SecondTable
(
B varchar(50)
, D varchar(50)
);
Alter Table SecondTable
Add Constraint FK_SecondTable_FirstTable_B
Foreign Key ( B )
References FirstTable ( B )
On Update Cascade;
Create Table ThirdTable
(
C varchar(50)
, E varchar(50)
);
Alter Table ThirdTable
Add Constraint FK_ThirdTable_FirstTable_C
Foreign Key ( C )
References FirstTable ( C )
On Update Cascade;
With respect to check constraints, one of the "cute" features of MySQL is that while it parses and accepts a check constraint in the Create Table statement, it completely ignores them with respect to evalution. To wit:
The CHECK clause is parsed but ignored by all storage engines.
Create Table documentation
Now, even if that were not the case, the Check constraint mechanism in the SQL language can only reference columns in the current table and thus would not help to solve your problem.
I'm not sure I fully understand the question. Would it not be sensible to have attributes B and C as Primary keys to Table 2, and 3 respectively. You could then reference them as foreign keys in the 1st table.
I have a problem in creating a table with a column that has two foreign Key relationships. Let me explain in detail.
I have three tables:
Table A - columns ID (primary key), Name
Table B - columns ID (primary key), Name
Table C - columns ID, Name, Detail
In C.Detail I have to store data from both other tables (A.ID & B.ID). So I tried to add two foreign key into the column C.Detail. During insert operation in Table B the following error occurs, and the same error message occurs while trying to insert data into Table A.
"The INSERT statement conflicted with the FOREIGN KEY constraint
"FK_C_A". The conflict occurred in database "X", table "dbo.A", column
A.ID."
Please, can anyone help us to rectify this problem? We don't want to add two columns in table C for two foreign keys.
Hopefully waiting for the reply.
I will suggest to introduce two new columns in Table C. (i.e AID and BID).
Create Foregin key on this news columns.
I could be wrong, but I think the way to go about doing this is to create a "parent" table for A and B that has A_B_parent.id(primary_key) and then have A and B both have foreign keys on their id to the parent table. Then C can also have a foreign key to the parent table.
This obviously ends up being really complex, so the better solution might just be to programmatically enforce the constraint rather than using foreign keys and then put a comment on the table.
Here's an example: Originally I have 3 tables. Table B references Table A. So now Table B has two primary keys. One used as the original primary key and the other one to enforce its relationship with Tabe A. Then I want Table B to have a many-to-many relationship with Table X. As I'm adding the relationship, MySQL Workbench added Table Y with both of Table B primary keys and one primary key in Table X. So Table Y now has three primary keys.
It seems like the second primary key from Table B in the junction table is unnecessary since I can identify Table B with the original primary key. So do I still need the extra primary key? Or perhaps I should not have an identifying relationship between Table A and B?
Table A and B have a relationship something like User has many Post. Post must belong to a User. But Post already has a primary key of its own, so does the foreign key to User need to be a primary key?
EDIT
Here's the scenario (diagram link below). The tables I'm focusing on are snippet, snippet_topic and tag. From what I know, since every snippet must belong to a snippet_topic, it has an identifying relationship. So I used the identifying relationship in MySQL Workbench and they added snippet_topic ID as a primary key. Afterwhich I added a m:n relationship for tag and snippet. MySQL Workbench added snippet_topic ID to the junction table (but I removed it). Is there anything wrong with my design? Or is there a more correct way to this?
Legend:
Yellow icon - primary key
Red icon - not null
each table should only have one primary key which is only about this table. If you then want a second column in Table A containing the values of the table B primary key thats find. Just set up a second index to get performance if requires
Originally I have 3 tables.
Ok.
Table B references Table A. So now
Table B has two primary keys. One used
as the original primary key and the
other one to enforce its relationship
with Tabe A.
No. Table B has one primary key and one foreign key. The foreign key might be part of the primary key, and it might not.
Then I want Table B to have a
many-to-many relationship with Table
X.
Ok.
As I'm adding the relationship, MySQL
Workbench added Table Y with both of
Table B primary keys and one primary
key in Table X. So Table Y now has
three primary keys.
A many-to-many relationship is typically implemented as a table that contains two foreign keys as its primary key. In your case, one foreign key is the primary key of Table B, and the other foreign key is the primary key of Table X. The primary key of Table B seems to contain two columns. The tables might look like this.
Table A: {a1, a2}
Table B: {b1, a1, b2, b3}, a1 references Table A
Table X: {x1, x2}
Table Y, which implements the m:n relationship, contains the keys from B and from X.
Table Y: {b1, a1, x1}, the two columns b1, a1 reference Table B; the column x1 references Table X
If you want better answers, edit your question and include the SQL DDL for your tables. Get the DDL by using SHOW CREATE TABLE.
You can not have more than one primary key. What you have there might be indexes. If the user_id column from table posts is included in your primary key, you can take it out and leave the primary key composed of just the id column.
I hope this helps
From your edited post - the only way to do this correctly is to have another table to hold the many to many relationship. Sniipit & snippit_topic have single primary keys and this new table has two columns with each of the primary keys
I'm writing an application that requires all users to access data on a central database using MySQL, and I was wondering something.
Let's say I have this setup.
CREATE TABLE A
(
id INT PRIMARY KEY AUTO_INCREMENT,
data INT NOT NULL;
);
CREATE TABLE B
(
id INT PRIMARY KEY AUTO_INCREMENT,
a_id INT,
FOREIGN KEY (a_id) REFERENCES A(id) ON DELETE SET NULL
);
Now, the way I want this set up is, table A must ALWAYS be referenced by a row in table B. However, a row in table B may or may not reference a row in table A. The relationship is 1:n in that multiple rows in table B can reference a single row in table A. I am just wondering if it is possible to have the MySQL database automatically delete a row in A if it is no longer referenced by any row in table B.
The idea here is that I can simply set a_id in table B to NULL and have the database cleanup whatever is left. I guess that's similar to Java garbage collection now that I think about it. If there is no key to automatically enforce the constraint, would a trigger executed after an update work?
EDIT: Adding in the additional relationship constraint.
Run the following query at a specific interval:
DELETE tableA
FROM tableA LEFT JOIN tableB B ON A.id = B.a_id
WHERE B.a_id IS NULL;
Or, to maintain real-time consistency, you could create an OnChange trigger on tableB that performs similar.
Is there a reason for the table structure you are using? The way you are using foreign keys looks backwards to me. Instead of placing your key in table B, you could move it to table A.
This would give you a structure that looked more like:
tableA columns tableB columns
id
b_id id
[values] [values]
fk: a.b_id=b.id
A record added to table A would require a corresponding field in table B, but B would be free to have no values in table A. Then if you wanted to clean out the values in table A, you could simply use:
delete from tableA where b_id=[recordIdToNull];
You could even set A's foreign key up to cascade actions taken on B, so any values deleted from B would also delete the corresponding rows in A.