I thought I had foreign keys setup on my tables, but despite having the correct syntax in my DDL, and even when attempting to add a constraint after the fact, nothing happens. I do not get any errors, and I get a message saying '10 row(s) affected Records: 10 Duplicates: 0 Warnings: 0'
Here is the definition for my table:
CREATE TABLE USERS_COURSES (
USERS_COURSES_ID INT NOT NULL AUTO_INCREMENT,
USER_ID INT NOT NULL,
COURSE_ID INT NOT NULL,
ROLE INT NOT NULL,
CONSTRAINT PK_USERS_COURSES PRIMARY KEY (USERS_COURSES_ID),
CONSTRAINT U_USERS_COURSES UNIQUE (USER_ID, COURSE_ID),
CONSTRAINT FK_USERS_COURSES_USERS FOREIGN KEY (USER_ID) REFERENCES USERS (USER_ID),
CONSTRAINT FK_USERS_COURSES_COURSES FOREIGN KEY (COURSE_ID) REFERENCES COURSES (COURSE_ID)
);
When I look at the table in MySQL Workbench, and via IntelliJ IDEA, all I see is a single index called FK_USERS_COURSES_COURSES (COURSE_ID)
I can run the following commands as many times as I like, and apparnetly nothing happens:
ALTER TABLE USERS_COURSES ADD CONSTRAINT FK_USERS_COURSES_USERS FOREIGN KEY (USER_ID) REFERENCES USERS (USER_ID);
ALTER TABLE USERS_COURSES ADD CONSTRAINT FK_USERS_COURSES_COURSES FOREIGN KEY (COURSE_ID) REFERENCES COURSES (COURSE_ID);
Here is what I see in my Database tab in IntelliJ:
What might be causing this? I need the foreign keys to prevent deletions, and right now this is not happening.
Check out the InnoDB documentation for MySQL.
While MySQL accepts foreign key declarations as valid syntax, at present only the InnoDB engine actually implements them. If it's not the default on your setup, include it in the table options - CREATE TABLE...ENGINE=InnoDB
Related
The following create table sql code is not producing the expected results.
CREATE TABLE mentorships (
mentor_ID INT NOT NULL,
mentee_ID INT NOT NULL,
status VARCHAR(255) NOT NULL,
project VARCHAR(255) NOT NULL,
PRIMARY KEY (mentor_ID, mentee_ID, project),
CONSTRAINT fk1 FOREIGN KEY(mentor_ID) REFERENCES co_employees(id) ON DELETE CASCADE ON UPDATE RESTRICT,
CONSTRAINT fk2 FOREIGN KEY(mentee_ID) REFERENCES co_employees(id) ON DELETE CASCADE ON UPDATE RESTRICT,
CONSTRAINT mm_constraint UNIQUE(mentor_ID, mentee_ID));
After running the code, when I check the indexes for the new table in phpmyadmin, I expect to see an index for fk1 as well as the others listed in the screenshot below. But as you can see in the screenshot, there is no fk1 index showing up.
Any idea as to why the fk1 index is not showing up or why it hasn't been created?
To clarify the points made in the comments above, here's what it says in the manual:
https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html
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.
(emphasis mine)
The "referencing table" in your case is mentorships, the table in which you are defining the foreign keys.
This statement from the manual is consistent with the points Jon Armstrong was making: the primary key satisfies the index requirement for the foreign key on mentor_id because that's the first column in the primary key index. But it does not satisfy the index for the foreign key on mentee_id because that's not the first column. Therefore it had to create a new index only for mentee_id.
Some how, my database has gotten into a bad state. I previously had a table named live_stream. When I tried to drop a foreign key constraint, I got an error that mariadb could not rename #sql-26_e7a to live_stream. Now when I try to run the following statement, I get this error.
Can't create table live_stream (errno: 150 "Foreign key constraint is incorrectly formed")
CREATE TABLE live_stream
(idbigint(20) NOT NULL PRIMARY KEY);
As you can see I don't have any foreign key constraints in the definition. If I try the exact same definition with a different table name, it works. If I try to drop the table, mariadb complains that live_stream doesn't exist. Its like the table or foreign key are stuck in a transaction or something like that.
I am using galara with maria db 10.3.
UPDATE
I believe the problem was introduced when a foreign key and unique index were given the same name. I recreated the scenario, and when I try to drop the index, mariadb prevents it.
* UPDATE 2 *
Here is the output of SHOW ENGINE INNODB STATUS;
* UPDATE3 *
Here are the steps to reproduce.
create table tb1
(
id bigint null,
constraint tb1_pk
primary key (id)
);
create table tb2
(
id bigint null,
tb1_id bigint null,
constraint tb2_pk
primary key (id),
constraint tb2_tb1_id_fk
foreign key (tb1_id) references tb1 (id)
);
ALTER TABLE tb2 ADD CONSTRAINT tb2_tb1_id_fk UNIQUE (tb1_id, tb1_id);
drop index tb2_tb1_id_fk on tb2;
The problem is that the unique constraint has the same name as the foreign key and references the same column twice.
SETTING
I have a rails application that references an external mysql server. I am about to push some changes to the rails application. I made some changes to my local/test version of the application's database using rails migrations, but my production/live version of the application's database is not on a server that has the rails application, so I don't think I can just run the rails migration on the mysql database.
QUESTION
How do I safely add the following column, key and constraint:
`item_id` int(11) DEFAULT NULL,
KEY `index_notifications_on_item_id` (`item_id`),
CONSTRAINT `fk_rails_f395ae520f` FOREIGN KEY (`item_id`) REFERENCES `items` (`id`) ON DELETE CASCADE,
and safely change the unique key:
UNIQUE KEY `item_id_and_user_id_stand_id_unique_index` (`item_id`,`user_id`,`stand_id`)
to
UNIQUE KEY `item_id_and_user_id_stand_id_notified_user_id_unique_index` (`item_id`,`user_id`,`stand_id`,`notified_user_id`),`)
ATTEMPTS
CONCERNING THE CONSTRAINT AND KEY
I try running:
ALTER TABLE notifications ADD FOREIGN KEY fk_rails_f395ae520f(item_id) REFERENCES items(id) ON DELETE CASCADE;
But, I run into 2 issues:
1: It names the key what I want the constraint to be named and makes up its own constraint name.
OUTPUT:
KEY `fk_rails_f395ae520f` (`item_id`),
CONSTRAINT `notifications_ibfk_2` FOREIGN KEY (`item_id`) REFERENCES `items` (`id`) ON DELETE CASCADE,
It requires me to temporarily set: set foreign_key_checks = 0; or else I get the error:
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (DB_NAME.#sql-3c9_49, CONSTRAINT #sql-3c9_49_ibfk_2 FOREIGN KEY (item_id) REFERENCES items (id) ON DELETE CASCADE)
and I do not know if doing that is "safe" to do on a production/live server.
CONCERNING THE COLUMN AND UNIQE KEY
I believe I have the column and unique keys safely added with:
ALTER TABLE notifications add COLUMN item_id INT(11) DEFAULT NULL;
ALTER TABLE notifications DROP INDEX index_notifications_on_user_id_and_notified_user_id, ADD UNIQUE KEY `item_id_and_user_id_stand_id_notified_user_id_unique_index` (stand_id, user_id, notified_user_id, item_id);
CLARIFICATION
The reason I bring up the column and unique key even though I may have it working is the same reason I gave a setting: I am new to this and may be taking a flawed approach to the whole scenario. I am hoping this context allows someone to call me out on it if that's the case.
UPDATE 1
ALTER TABLE notifications ADD CONSTRAINT fk_rails_f395ae520f FOREIGN KEY index_notifications_on_item_id(item_id) REFERENCES items(id) ON DELETE CASCADE;
outputs:
CONSTRAINT `fk_rails_f395ae520f` FOREIGN KEY (`item_id`) REFERENCES `items` (`id`) ON DELETE CASCADE,
Which is what I want, but I am still working on the KEY section.
UPDATE 2
ALTER TABLE notifications add COLUMN item_id INT(11) DEFAULT NULL;
ALTER TABLE notifications DROP INDEX index_notifications_on_user_id_and_notified_user_id, ADD UNIQUE KEY `item_id_and_user_id_stand_id_notified_user_id_unique_index` (stand_id, user_id, notified_user_id, item_id);
CREATE INDEX index_notifications_on_item_id ON notifications (item_id);
ALTER TABLE notifications ADD CONSTRAINT fk_rails_f395ae520f FOREIGN KEY index_notifications_on_item_id(item_id) REFERENCES items(id) ON DELETE CASCADE;
I believe these four lines in sequence answers the question of how to manually handle what my rails migration does. But, I am going to leave this question here. The question that remains is: "is it a terrible idea to do what I just did? and if so, how to do proceed?"
I am trying to insert pseudo data into my db to get going, and in one particular table I have two columns which are FK's and PK's of the table; fk_product_manf_code and fk_content_id. To my understanding, these are considered composite keys in their current state.
So I add data to the table:
fk_product_manf_code fk_content_id
NOV-ABC123 1
I then want to associate another content_id to the same product_manf_code, so I perform the following:
INSERT INTO `mydb`.`package_contents`
(`fk_product_manf_code`, `fk_content_id`)
VALUES
('NOV-ABC123', 2);
However I'm greeted with the following error:
Error Code: 1062. Duplicate entry 'NOV-ABC123' for key 'fk_product_manf_code_UNIQUE'
I don't understand what's going, because I thought a composite key makes 2 columns unique? So why is it kicking up a fuss about just 1 column being unique?
Here is the table CREATE statement
CREATE TABLE `package_contents` (
`fk_product_manf_code` varchar(255) NOT NULL,
`fk_content_id` int(11) NOT NULL,
PRIMARY KEY (`fk_content_id`,`fk_product_manf_code`),
UNIQUE KEY `fk_content_id_UNIQUE` (`fk_content_id`),
UNIQUE KEY `fk_product_manf_code_UNIQUE` (`fk_product_manf_code`),
CONSTRAINT `content_id` FOREIGN KEY (`fk_content_id`) REFERENCES `contents` (`content_id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `product_manf_code` FOREIGN KEY (`fk_product_manf_code`) REFERENCES `products` (`product_manf_code`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
So, you are learning why composite primary keys are a pain, especially for foreign key constraints. Not only are integer keys more efficient, but a single key is easier to work with.
I would suggest changing your table structure to be more like this:
CREATE TABLE package_contents (
package_contents_id int not null auto_increment primary key,
fk_product_manf_id int NOT NULL,
fk_content_id int(11) NOT NULL,
UNIQUE KEY (fk_content_id, fk_product_manf_id),
CONSTRAINT content_id FOREIGN KEY (fk_content_id)
REFERENCES contents(content_id) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT product_manf_code FOREIGN KEY (fk_product_manf_id)
REFERENCES products(product_manf_id) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Note that I changed the manufacturer code to an id as well. This should also reduce the size of the table, assuming that the "code" is longer than 4 bytes.
If you do this for all your tables, the database will be a bit more efficient, and you won't need superfluous unique constraints. The foreign key constraints should always be to primary keys (unless there is a very good reason for using a different unique key).
In have a many-to-many linking table and I'm trying to set up two foreign keys on it. I run these two statements:
ALTER TABLE address_list_memberships
ADD CONSTRAINT fk_address_list_memberships_address_id
FOREIGN KEY index_address_id (address_id)
REFERENCES addresses (id);
ALTER TABLE address_list_memberships
ADD CONSTRAINT fk_address_list_memberships_list_id
FOREIGN KEY index_list_id (list_id)
REFERENCES lists (id);
I would expect that when I run SHOW CREATE TABLE address_list_memberships I'd see this:
[...]
KEY `index_address_id` (`address_id`),
KEY `index_list_id` (`list_id`),
CONSTRAINT `fk_address_list_memberships_list_id` FOREIGN KEY (`list_id`)
REFERENCES `lists` (`id`),
CONSTRAINT `fk_address_list_memberships_address_id` FOREIGN KEY (`address_id`)
REFERENCES `addresses` (`id`)
But instead I get this:
[...]
KEY `index_list_id` (`list_id`),
CONSTRAINT `fk_address_list_memberships_list_id` FOREIGN KEY (`list_id`)
REFERENCES `lists` (`id`),
CONSTRAINT `fk_address_list_memberships_address_id` FOREIGN KEY (`address_id`)
REFERENCES `addresses` (`id`)
It looks as though only one index is there. Seems to contradict the MySQL docs which say MySQL automatically creates an index on the referencing column whenever you create a foreign key.
I've noticed this only-one-index thing every time I create two FKs on a table whether I use a GUI tool such as CocoaMySQL or SQLyog, or whether I do it on the command line.
Any illumination of this mystery would be very much appreciated.
I just tried it and it works fine for me. I copied and pasted the ALTER statements you wrote and here is what I get:
mysql> show create table address_list_memberships;
CREATE TABLE `address_list_memberships` (
`address_id` bigint(20) unsigned NOT NULL,
`list_id` bigint(20) unsigned NOT NULL,
KEY `index_address_id` (`address_id`),
KEY `index_list_id` (`list_id`),
CONSTRAINT `fk_address_list_memberships_list_id`
FOREIGN KEY (`list_id`) REFERENCES `lists` (`id`),
CONSTRAINT `fk_address_list_memberships_address_id`
FOREIGN KEY (`address_id`) REFERENCES `addresses` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
I'm using MySQL 5.0.51a on Mac OS X.
edit: Try the following query to get all the indexes MySQL thinks exist on your table:
SELECT * FROM information_schema.key_column_usage
WHERE table_schema = 'test' AND table_name = 'address_list_memberships'\G
(I used the 'test' database for my test; you should replace this string with the name of the schema where your table is defined.)
It doesn't really matter. You still have an index on list_id. MySQL requires any foreign key constraint to also have an index on the referencing fields. Since both index_list_id and fk_address_list_memberships_list_id are built on list_id, MySQL probably sees this and uses index_list_id as the index, renaming it to fk_address_list_memberships_list_id. You could even skip declaring the index, since MySQL will do it implicitly in the version you are using.