Do I have to fill foreign key values? - mysql

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.

Related

I can't select a column to specify a foreign key

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.

I'm getting Error: Missing index on column(s). when I try to create a relationship between tables in phpMyAdmin Designer tool

I need to create the database schema and include it in my software requirements specification for my school project, however, when I try to create a relationship between 2 tables, I get Error: Missing index on column(s).
I think #HazarathChillara has this right; you need to create primary, unique, or index keys.
You said every table has an primary key, but did you make each foreign and referenced key an index as well? It sounds like you neglected to properly set up your table structure; I only get the error when I don't have a primary key or index on the particular columns I'm working with.
"MySQL requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan"
You can just put an INDEX on the foreign key (often my referenced key is a primary key anyway, so I don't need any additional key on that column).
This error appears only when you neglect table structure. Make sure that you Indexed a foreign key as well. you can see i marked how could i select my foreign key as index.In this Image I am indexing selected, 'sr' my foreign key
As Usman Khan said you have to go to the structure tab of the particular table and clicked on more options and select 'INDEX' for the foreign key.
the below image will help you how to do it
I think i have another simple solve,
thing is, phpMyAdmin wont allow the addition of foreign keys to an already available data entry, so here is the my simple solve,
1. ensure to backup your database
2. confirm that your data was backed-up securely, recommended Offline backups
4. delete all data entries in all tables that will be part of the new relationship.
5. now Create the relevant relationships.
6. be sure you have created all required and preferred relations to avoid the need to
export data again

Why do MySQL foreign key constraint names have to be unique?

I've noticed that I can't create two different foreign key constraints that have the same name, regardless of the set of tables in the schema that they're affecting.
Which I can cope with that, I couldn't find in the MySQL documentation where it says this is the case, nor why its the case. I'm using InnoDB, so maybe it's something specific to that, but I'm not finding that documented either.

Can't create Foreign Key

I wrote a simple SQL statement to create addon for wordpress - just few tables with relations.
I decided to test it a bit in MySQL workbench and all goes fine, got tables and relations. Then I'm trying to forward engineer it - workbench slightly changes the text... and then reports an error:
Honestly, I'm quite puzzled here... schema looks very simple, I'm sure I didn't make any type so why the error?
Make sure the columns are the same in both tables including sign for the foreign key and the primary key.
Could it be the engine? InnoDB handles foreign keys, but I think the standard MyISAM doesn't, or at least, didn't always, depending on version.
If you are trying to add the foreign key restriction to an attribute in a table containing data you can have problems if the foreign key restriction is not fulfilled. I mean, if you have a value in the attribute that now is a foreign key, and this value is not contained in the attribute of the table that the foreign key references.

Cascading delete removes unintended records

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