What I want to do is very simple. Select a column(my foreign key) and then specify the referenced column.
But it seems like MySql workbench has a bug. I can´t select my foreign key. Does anyone know how to solve this?
.
Mysql version > 8.0.12
Does anyone know how to solve this?
General rule is that both columns has to be of same type and referenced column has to be indexed (eg. primary key).
If you share SHOW CREATE TABLE <table> for both tables, I can provide more info.
Here is list of all requirements from official documentation:
Parent and child tables must use the same storage engine, and they
cannot be defined as temporary tables.
Creating a foreign key constraint requires at least one of the SELECT,
INSERT, UPDATE, DELETE, or REFERENCES privileges on the parent table
as of 5.6.22.
Corresponding columns in the foreign key and the referenced key must
have similar data types. The size and sign of integer types must be
the same. The length of string types need not be the same. For
nonbinary (character) string columns, the character set and collation
must be the same.
MySQL supports foreign key references between one column and another
within a table. (A column cannot have a foreign key reference to
itself.) In these cases, a “child table record” refers to a dependent
record within the same table.
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.
InnoDB permits a foreign key to reference any index column or group of
columns. However, in the referenced table, there must be an index
where the referenced columns are the first columns in the same order.
Hidden columns that InnoDB adds to an index are also considered (see
Section 14.6.2.1, “Clustered and Secondary Indexes”).
NDB requires an explicit unique key (or primary key) on any column
referenced as a foreign key. InnoDB does not, which is an extension of
standard SQL.
Index prefixes on foreign key columns are not supported. Consequently,
BLOB and TEXT columns cannot be included in a foreign key because
indexes on those columns must always include a prefix length.
InnoDB does not currently support foreign keys for tables with
user-defined partitioning. This includes both parent and child tables.
This restriction does not apply for NDB tables that are partitioned by
KEY or LINEAR KEY (the only user partitioning types supported by the
NDB storage engine); these may have foreign key references or be the
targets of such references.
A table in a foreign key relationship cannot be altered to use another
storage engine. To change the storage engine, you must drop any
foreign key constraints first.
Related
When I add a foreign key constraint to my table, SHOW INDEX doesn't show any new indices, but the overall space used by the indices in that table increases. Apparently, the index for the field I put a constraint on does get created implicitly, but MySQL doesn't want me to tell about its existence. Is there a way to see those implicit indices anyway?
The table type is InnoDB.
Do I have to fill the field of a foreign key in MySQL or any other database manager?.
I'm writing the data of a table and when I get to the field that is a FK from another table, I have to write something, is this necessary?
I understand that the value in that FK is stored inside the parent table where it comes from.
You have to provide a value unless the foreign key column is nullable.
It depends on whether the is actually a foreign key constraint in place (available in InnoDB only). In some cases frameworks, applications, or database management tools create "false" foreign keys that exist only in the application and not actually in the database. Also, the limits on how you can insert/update/delete data realted to the foreign keys can differ based on the type on constraint in place.
Here is the MYSQL documentation for definitive information:
http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html
Specifically, look at the "Referential Actions" section for comments on the behavior between the tables.
I typically develop in MS Access and occasionally connect to a MySQL back end. I have a MySQL back end that isn't cascading deletes as I'd expect when I delete records. I'm wondering if it's because of how I've set up the table relationships (foreign keys). I don't know enough about MySQL to know if I've done this right. In designer view I set up the relationships using the designer view in MySQL. For a composite primary key field (InterviewID, Coder ID) in tblInterviews I created two separate relations to tblSB for each of these two primary key fields (tblSB includes a 3rd field, SBid, as its composite PK). The designer view is a little different from Access in that you can't highlight more than one field at a time to set up relationships. I did find forums that discuss the syntax for setting up the relationship with the foreign key but I don't know if it's equivalent to what I did in designer. I suspect not because currently when I try to delete a specific record (unique InterviewID, CoderID combination) ALL interview records for the CoderID in the InterviewID, CoderID combination get deleted (and this cascades through to other child tables as well). I also am wondering if I need to set up my primary key in a way that I am not currently doing (e.g., setting it up as an index, also). Any help would be appreciated. Thanks in advance.
To see what you've created, look at the DDL. (SHOW CREATE TABLE)
To enforce foreign key constraints--including cascading deletes--you probably want to use the innodb engine. The myisam engine will accept DDL that declares foreign keys, but it won't enforce them.
MySQL will let a foreign key target a non-unique column. The MySQL docs say
Deviation from SQL standards: A FOREIGN KEY constraint that references
a non-UNIQUE key is not standard SQL. It is an InnoDB extension to
standard SQL.
They call it an extension to SQL. I call it a mistake.
It means you can declare tblSB.interviewID as a foreign key referencing tblInterviews.interviewID. A standard SQL dbms wouldn't allow that.
The 5.6 docs say
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 and NOT NULL
keys.
To my way of thinking, they're saying, "It was a bad idea, but we don't know how to fix it. So it's up to you to avoid it. We could warn you when you try it, but we're not going to do that, either."
Based on your comments, I'd say this constraint is right . . .
CONSTRAINT tblInterviewRecordtblSB
FOREIGN KEY (InterviewID, CoderID)
REFERENCES tblinterviewrecord (InterviewID, CoderID)
ON DELETE CASCADE ON UPDATE CASCADE
but these two are not, and should be deleted.
CONSTRAINT tblSB_ibfk_1
FOREIGN KEY (InterviewID)
REFERENCES tblinterviewrecord (InterviewID)
ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT tblSB_ibfk_2
FOREIGN KEY (CoderID)
REFERENCES tblinterviewrecord (CoderID)
ON DELETE CASCADE ON UPDATE CASCADE
Does Column with ForeignKey creates index automatically?
Or I need to do that manually adding index=True?
some_field = Column(Integer, ForeignKey(SomeModel.id))
You do need to either specify index=True or create an Index object explicitly:
Index('myindex', mytable.c.col1, mytable.c.col2, unique=True), which allows more control over other parameters of the index, such as the name and support for more than one column.
See Indexes for more information.
As van's answer indicates, you should explicitly add an index as indicated by the docs.
The implementation of foreign keys is database specific, and some DBs such as MySQL will still automatically create an index for foreignkey column, but others will not. See discussion in comments above.
e.g from MySQL docs:
MySQL requires that foreign key columns be indexed; if you create a
table with a foreign key constraint but no index on a given column, an
index is created.
I have a MySQL database with about 10 tables, and about 6 of them are linked to each other in some way or another. MY question is, should i be specifying INDEXES on the foreign keys?
Thanks
from the docs:
"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. "
source: http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html
Yes you should, if cardinality is high enough.
Well, just mentioned that it's MySQL-specific question. Seems so that you have an index created automatically when not present with MySQL.
Gryphius's answer is more adequate then.