Two Foreign Keys on one column - mysql

I have two tables in MySQL, named manuals and library. Both could have uploaded files, so I have made an third table, named files. In files, I have a column parent_id. Can I make parent_id as foreign key from both manuals and library?
I am using Laravel (4.2) and tried this, but it doesn't work:
$table->integer('parent_id')->unsigned();
$table->foreign('parent_id')->references('id')->on('library');
$table->foreign('parent_id')->references('id')->on('manuals');

No. You cannot have multiple foreign keys on the same column. From the MySQL documentation:
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, “child table records” really refers to dependent records within the same table.
The reason for this is that MySQL won't be able to differentiate between the parents. Laravel (or any other framework) does not provide a work around for this issue.
This question as been asked in slightly different forms before. Example: it is possible to reference one column as multiple foreign keys

Related

Mysql Multiple Foreign Key for a attribute in table

I want to design a database for e-learning. Here is the case.
"Each subject has 2 hierarchy i.e. ScoringComponent and Competency.Each hierarchy is updated every period. Each hierarchy has unlimited depth-level. The lowest level of the ScoringComponent should be mapped to one or more lowest level of competency hierarchy."Relation between the ScoringComponent and Competency Image
Based on the case, i tried to design the database. The result is like Database Design.
The issue in the database design is the multiple Foreign Key for Year-Period Attributes.
From this issue, i want to create the table without Foreign Key and handle the data validity in the application code.
Is it okay for me to remove the Foreign key from the table? and is there any suggestion for my case?
Thank you.
I would not move away from using a foreign key in your table, if you need it.
Are you the only one that will know how the data is arranged in the database?

Are these too many foreign keys?

I'm using MySQL and have been planning out the database structure for a system I'm building out. As I've been going along, I started to wonder if it was acceptable to have a particular foreign key constraint in many different tables. From what I understand, it would be fine, as it makes sense. But I'd like to double check.
For example, I have a users table, and I use the user_id as a foreign key for many tables, sometimes multiple times in one table. For example, I have a one-to-one relationship with a user_settings table, which of course stores the user_id. And then I have a companies table, which alone has a few references to the user_id key. In this case, I have a column that keeps track of the user that created the company in the system (created_by), a column for the main contact (main_contact, who is also a user of the system), and there might be another reference. So that alone, already has the user_id key being used as a foreign key constraint 3-4 times.
Just to add another bit of info, I have a tasks table and that of course needs to reference the user_id to keep track of who it's assigned to, and I also have another column that keeps track of the user that created the task. That would be assigned_to and created_by, respectively.
There are more tables though that reference back to that key. I might be up to 8 references already. I do believe I've designed it properly so far, but based on what I've mentioned, does this sound fine?
Your foreign key usage seems fine to me - after all, you are simply representing logical relationships between your tables.
A user within your system interacts with the data in many ways, and to define these relationships your approach is the correct one.
The key point I think is that under a lot circumstances, you won't always want (or need) to make all the joins that represent your relationships - simply the ones that you need in that context.
As per my undestanding the way you are defining is fine i.e to use a user id to many tables as foreign key.
If your line:: I have a companies table, which alone has a few references to the user_id key doesn't mean that you are using multipe user_id in same table and I know you are not.

Insert record with foreign key constraints

First of all, my apologies if this question is a duplicate - but I find it difficult, putting short, precise words on my problem.
I've got these entities.
The left contains several groups (like in Unix, in order to make data available to a whole group at once) and at the moment, it's always 1. The right one contains projects - and the middle one makes sure, that one group can gain access to several projects.
As you can see, there are foreign key relationships among them. Now, I want to create a new project in nmd__tree. When doing that, it returns an error:
Cannot add or update a child row: a foreign key constraint fails
(nmd.nmd__tree, CONSTRAINT FK_nmd__tree FOREIGN KEY (treeid)
REFERENCES nmd__helperusergrouphierarchy (treeidfk))
This makes sense, since the nmd_tree relies on a valid foreign key in the helper entity - but at the same time, it presents the problem, that the treeidfk isn't yet known, since it is autogenerated in nmd__tree
A solution could be to remove the relations, insert the record in nmd__tree, extract the newly written primary key (treeid) and create a record in the middle helper entity with the new id. It will work, but is really not very elegant. Also, removed relations presents other, potential problems.
My intentions are to create a query, that deals with this problem by creating both records at once. I know, it isn't possible to make a double insert and found this suggestion (my version doesn't write any records), as well as an article, suggesting stored procedures, which I don't see should make a difference
I would really appreciate a push in the right direction, please.
It seems you've got your constraints defined in the wrong direction; The middle table should have two foreign key constraints not the two end tables. That way, you can insert records in the two end tables and then link them up using the middle table.

Using enumerations in mySQL Workbench

Im creating a database design in MySQL Workbench. I want to have a enumarated table which holds some standard values. The values of the enumaration table needs to be linked to a row in my other table. So i have a table called 'club' which holds a row 'club_soort'. The row 'club_soort' needs to relate to the enumaration table.
Also, I want to use my tables (when i'm ready with my database design) into phpMyAdmin.
I understand the concept of enumaration, but I can't implement it. I hope someone can help me!
Thanks!
Rather than using enumerations, you should use what's known as a lookup or reference table. This table would contain your enumerations and be referenced as a foreign key by the parent table.
As an example, this would look like:
parent_table
------------ club
id ----
club_soort ----------> soort
ENUM values cannot be linked to any MySQL structures. It can contain only static data.
Are you talking about primary keys?
Being a relational database, mysql uses primary keys and indexes to joint data the way you want to achieve.
Primary keys join tables in an efficient way, PK in the the origin or parent table and FPK, Foreign Primary Key in the related table.
When creating a table, in mysql workbench or phpmyadmin, define a primary key, just one per table and if needed indexes and if needed foreign keys.
Use union statements to join two or more tables.
Always use numeric keys data_type INT instead of natural, string keys. Also make then autoincrement and Not Null.
mysqlworkbench has an exporting tool, which allows you to export each created table, including their keys, indexes and cascading. You can copy and paste to create tables in phpmyadmin.

No foreign key constraints and need to do a complicated delete

I have a website which I have been working on creating very rapidly, and now am paying back some technical debt. I have a complicated issue:
My site deals with scheduling hikes. Once you create a hike, it has many things associated with it:
a message board, list of attendees, the group it belongs to, the carpool, route, trailhead, etc.
Here is an example so you can see what I am talking about:
http://www.comehike.com/hikes/scheduled_hike.php?hike_id=172
The technical debt I am talking about is that I never made foreign keys in the DB, and now need to do a cascade delete, and I am not sure how to go about it so that I don't introduce a million bugs :)
Should I make foreign keys for all the tables now? How should I do this?
Thanks,
Alex
Check out the MySQL docs on FOREIGN KEY Constraints. Note that you'll need to be using innoDB tables.
ALTER TABLE <tablename>
ADD CONSTRAINT <fkname> FOREIGN KEY <index name>(<columns>)
REFERENCES <othertable> (<columns>)
ON DELETE CASCADE
I would suggest creating foreign keys for the tables in your DB. This will be a more robust way of dealing with the problem you are facing. You obviously understand what a foreign key imposes on the database, and how to deal with the keys.
If I was faced with this problem, I would use a graphical interface for the database if I had one (e.g. PhpMyAdmin), otherwise a quick google brings up some tutorials.
EDIT: From the linked tutorial, in a many-to-one relationship, you pace the key on the "many" table, indicating that a certain column in that table can only have values that are present in a certain column in the "one" table. Hi the link for a worked example.
When adding keys to a table that already has data, you may not be able to add the foreign key if some of the data is malformed. For example, if you have a phone number table referencing a person table (many phone numbers to one person) and you have any phone numbers with an invalid person_id (maybe person 5 was deleted and there is still a phone number with a person_id of 5) you will be unable to create the foreign key until you remove the offending phone number.
if you have not made formal foreign keys, the have you made the keys some other way that permits linking the tables or are all tables unrelated ?
If there is anyway to relate the tables then you will simply have to write a Cascading Delete code.
Otherwise its probabely a redesign or add in foreignkey fun. =))
If you have not already get yourself a copy of MySQL Workbench and redesign it from there adding in the foreign keys. This will generate the SQL code for you too.
I would go with creating foreign keys as well but if there is any reason that stops you from doing so there is another solution which is creating Triggers. You can tell triggers to basically do anything you want when an update,delete or insertion occurs to a table in the database including changing other tuples in other tables. Here are a couple of tutorials on how to create triggers:
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_7004.htm
http://msdn.microsoft.com/en-us/library/ms189799.aspx
the first one seems more direct and clearer but if none of them helps just search google for DB triggers and you're all set!
I hope this helps :)