Creating foreign keys on already indexed columns with MySQL Workbench - mysql

I am creating a database model with Workbench and create the following table:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) )
ENGINE = InnoDB
It has a primary key, and a unique key on my second column.
When I create foreign key constraints on them, Workbench automatically adds two indexes:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) ,
INDEX `FKOne` (`idtable1` ASC) , //here
INDEX `FKTwo` (`uniquecolumn` ASC) , //(I don't want this!)
CONSTRAINT `FKOne`
FOREIGN KEY (`idtable1` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `FKTwo`
FOREIGN KEY (`uniquecolumn` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
(The above is the forward-engineered script after adding the foreign keys to my model)
I have four indexes now.
This is what the MySQL Reference Manual says:
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.
So I understand there is no need to create indexes FKOne and FKTwo, since there are already a Primary Key and a Unique index, on the same columns, in the same order. Yet MySQL Workbench doesn't allow me to delete indexes FKOne and FKTwo. And I think I should be able to do this:
CREATE TABLE IF NOT EXISTS `Database`.`table1` (
`idtable1` INT NOT NULL ,
`uniquecolumn` INT NOT NULL ,
PRIMARY KEY (`idtable1`) ,
UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) ,
CONSTRAINT `FKOne`
FOREIGN KEY (`idtable1` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `FKTwo`
FOREIGN KEY (`uniquecolumn` )
REFERENCES `Database`.`table2` (`idtable2` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB
Am I right? Would this code work? Is there some way to do it with Workbench? (Apart from deleting those two lines at the last moment before forward-engineering).
Or maybe MySQL is smart enough to refrain from creating totally redundant indexes and I don't have to worry about it...?

(I'm assuming this is when defining a model.)
See Bug 53277, where I mention the following obscure workaround:
You start with a foreign key and its corresponding generated index that you want to get rid of. Make sure the key is (at least temporarily) on a single non-unique column. In the Indexes tab, change the Type to UNIQUE. Then go to the Columns tab, where UQ is now checked, and uncheck it. The unwanted index is eliminated!

Related

MySQL Workbench reports ERROR 1822: Failed to add the foreign key constraint. Missing index for constraint

I'm creating a mysql db based from an EER model sql script and when trying to do the conversion (all in MySQL Workbench), I'm getting the error above. My goal is to reference the adoption_entity_id on the adoption_entity table from 2 columns in attachment table (sent_from and from_to).
I have 2 tables, one of which is the attachment:
-- -----------------------------------------------------
-- Table `afth_db`.`attachment`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `afth_db`.`attachment` ;
CREATE TABLE IF NOT EXISTS `afth_db`.`attachment` (
`attachment_id` BIGINT NOT NULL,
`sent_from` INT NULL,
`sent_to` INT NULL,
`attachment_description` LONGTEXT NULL,
`attachment_uploaded` DATETIME NULL,
`attachment_uploaded_by` VARCHAR(255) NULL,
`adoption_case_num` BIGINT NOT NULL,
PRIMARY KEY (`attachment_id`),
INDEX `fk_attachment_adoption_case1_idx` (`adoption_case_num` ASC) VISIBLE,
UNIQUE INDEX `attachment_id_UNIQUE` (`attachment_id` ASC) VISIBLE,
UNIQUE INDEX `adoption_case_num_UNIQUE` (`adoption_case_num` ASC) VISIBLE,
INDEX `fk_attachment_adoption_entity1_idx` (`sent_from` ASC, `sent_to` ASC) VISIBLE,
UNIQUE INDEX `sent_to_UNIQUE` (`sent_to` ASC) VISIBLE,
UNIQUE INDEX `sent_from_UNIQUE` (`sent_from` ASC) VISIBLE,
CONSTRAINT `fk_attachment_adoption_case1`
FOREIGN KEY (`adoption_case_num`)
REFERENCES `afth_db`.`adoption_case` (`case_num`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_attachment_adoption_entity1`
FOREIGN KEY (`sent_from` , `sent_to`)
REFERENCES `afth_db`.`adoption_entity` (`adoption_entity_id` , `adoption_entity_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
and the other is the adoption entity:
-- -----------------------------------------------------
-- Table `afth_db`.`adoption_entity`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `afth_db`.`adoption_entity` (
`adoption_entity_id` INT NOT NULL,
`adoption_entity_type` VARCHAR(255) NULL,
PRIMARY KEY (`adoption_entity_id`),
UNIQUE INDEX `adoption_entity_id_UNIQUE` (`adoption_entity_id` ASC) VISIBLE)
ENGINE = InnoDB
The error states in detail:
Operation failed: There was an error while applying the SQL script to the database.
ERROR 1822: Failed to add the foreign key constraint. Missing index for constraint 'fk_attachment_adoption_entity1' in the referenced table 'adoption_entity'
I'm not sure why its been giving me this issue though. I've tried several solutions from setting type to 'unique index', 'index' for fk_attachment_adoption_entity1 along with the other columns involved, but I can't seem to be able to get rid of the error. I've also tried deleting and recreating the 1-1 relationship but that didnt help either. Can anyone tell me if I'm doing something wrong here on the EER model design?
You are trying to create one foreign key reference, which spans over the two columns sent_from and sent_to to single rows in the adoption_entity table. That's not what you want. You want to create two separate foreign key references instead for the individual columns sent_from and sent_to. So the constraint parts should look like this:
CONSTRAINT `fk_attachment_adoption_entity_from`
FOREIGN KEY (`sent_from`)
REFERENCES `afth_db`.`adoption_entity` (`adoption_entity_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION),
CONSTRAINT `fk_attachment_adoption_entity_to`
FOREIGN KEY (`sent_to`)
REFERENCES `afth_db`.`adoption_entity` (`adoption_entity_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)

MySQL table foreign key indexes on primary index columns

I've created a table for accounts/users with a primary key (UsersID, AccountsID) like below. Should I add the index for the Users table?
create table AccountsUsers
(
AccountsID int unsigned not null,
UsersID int unsigned not null,
Roles bigint unsigned null,
primary key (UsersID, AccountsID),
constraint AccountsUsers_Accounts_ID_fk
foreign key (AccountsID) references Accounts (ID)
on update cascade on delete cascade,
constraint AccountsUsers_Users_ID_fk
foreign key (UsersID) references Users (ID)
on update cascade on delete cascade
)
engine=InnoDB
;
create index AccountsUsers_Accounts_ID_fk
on AccountsUsers (AccountsID)
;
MySQL will create the necessary indexes for the foreign key automatically, if necessary.
In the case of your foreign key on UsersId, it can use the left column of your primary key. It doesn't need to create a new index for that foreign key.
In the case of your foreign key on AccountsId, MySQL will create a new index automatically. It can't use the fact that AccountsId is part of your primary key, because it isn't the left-most column.
After you do the CREATE TABLE, run SHOW CREATE TABLE AccountsUsers and you should see the new index it created for AccountsId.
From the documentation
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, if you don't already have the required indexes on the columns of your referencing table (AccountsUsers), MySQL will create them for you.
If the columns in the referenced tables (Accounts and Users) are not indexed you will get an error. Your's look like they will be Primary Keys on their respective tables, so you should be fine.

MySQL error 1022 when creating table

MySQL Workbench came up with the following SQL to create a table:
CREATE TABLE IF NOT EXISTS `mydb`.`errors_reports` (
`error_id` INT NOT NULL ,
`report_short` VARCHAR(15) NOT NULL ,
PRIMARY KEY (`error_id`, `report_short`) ,
INDEX `error_id_idx` (`error_id` ASC) ,
INDEX `report_short_idx` (`report_short` ASC) ,
CONSTRAINT `error_id`
FOREIGN KEY (`error_id` )
REFERENCES `mydb`.`errors` (`error_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `report_short`
FOREIGN KEY (`report_short` )
REFERENCES `mydb`.`reports` (`report_short` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
which looks fine to me, and there are a bunch of other very similar tables in my database which MySQL was perfectly happy to create.
But this one...
ERROR 1022 (23000): Can't write; duplicate key in table 'errors_reports'
I can't for the life of me see any duplicate keys here. There's only one key defined!
I'm running MySQL 5.6 with a fresh default install. There's nothing in the error log.
Ideas?
Edit: through a process of elimination (going back to the simplest possible definition of the table, then gradually adding bits back in) the problem appears to be this bit:
CONSTRAINT `error_id`
FOREIGN KEY (`error_id` )
REFERENCES `mydb`.`errors` (`error_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
which is particularly odd as there is identical code in several other table definitions and those are perfectly okay!
The problem is that the name of a foreign key can not be the same as another foreign key in the entire model.
Imagine this situation
Catalog --> Supplier
Product --> Supplier
if the name of the foreign key in table Catalog for supplier is "supplier" and you assigned the same name in product table then the foreign keys names will "collide".
You need to name them differently..
For example:
catalog_supplier
product_supplier
It seems you're creating an index on the foreign key columns. When creating a foreign key in InnoDb, one will be created automatically.
See this thread.
Try using INSERT IGNORE instead of INSERT where INSERT IGNORE will not insert a new row if a duplicate primary key is found. This should help resolve the problem temporary but I would recommend truncating the table.

MySQL: What kind of index should I create in this table?

Suppose this is the SQL code of the table:
CREATE TABLE `user_is_in` (
`id_user` INT NULL ,
`id_city` INT NULL ,
`when` DATETIME NULL ,
INDEX `fk_user` (`id_user` ASC) ,
INDEX `fk_city` (`id_city` ASC) ,
CONSTRAINT `fk_user`
FOREIGN KEY (`id_user` )
REFERENCES `user` (`id` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `fk_city`
FOREIGN KEY (`id_city` )
REFERENCES `city` (`id` )
ON DELETE SET NULL
ON UPDATE CASCADE)
ENGINE = InnoDB;
The use of the table is to store kind of Foursquare checkins (A user was registered on one place at one time).
Now I have 2 options:
Create an unique index with the 3 fields and no primary key:
UNIQUE INDEX id_user_is_in_UNIQUE (id_user ASC, id_city ASC, when ASC)
Create an additional classic id autoincrement field
I don't like the 2nd option because I want to create queries over users and cities (i.e.: search all users who made a checkin in a city on one date)
Thanks in advance.
You should do both. Add an auto-incrementing primary key and add a uniqueness constraint against all three columns. With a separate system assigned keys you make it easier to define foreign keys to this new table, if and when eventually required. And having the uniqueness constraint against all three columns will ensure that duplicate data is not created.
Some quick side notes:
Since this is an association table, your columns really should be
NOT NULL.
You probably want to CASCADE delete's of a city down to the
association table.

MySQL Create table with indexes error

Ok, so I am creating tables in MySQL with indexes and foreign keys. I use MySQL Workbench to create the tables and then have it forward engineer a SQL create script (I do better in a visual DB environment than just writing out the SQL code by hand right away).
The problem is many times when I import the sql script into mysql, I get the classic eror:
#1005 - Can't create table 'db.tablename' (errno: 121)
I've managed to figure out the problem each time, usually index/foreign key related, but now I'm starting to get irritated at having to fix it each time. I don't really understand what the problem is (especially when a MySQL product is creating sql code for its own database). Below is some code that typically causes the problem.
CREATE TABLE IF NOT EXISTS `db`.`groupMembers` (
`groupMembersID` INT NOT NULL AUTO_INCREMENT ,
`groupID` INT NOT NULL ,
`userID` INT NULL ,
PRIMARY KEY (`groupMembersID`) ,
INDEX `group` (`groupID` ASC) ,
INDEX `user` (`userID` ASC) ,
CONSTRAINT `group`
FOREIGN KEY (`groupID` )
REFERENCES `db`.`groups` (`groupsID` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `user`
FOREIGN KEY (`userID` )
REFERENCES `db`.`users` (`usersID` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB;
The error usually comes from the first INDEX definition - even when I take out the index definition, I just get the error at the the first foreign key constraint definition. I've checked, and the foreign key remote column and the local column are the same data-type and size.
"errno 121 means a duplicate key error"
Constraints must have an unique name in the database, you might wanna change your FK names. Like so, FK_groupMembers_group and FK_groupMembers_user.