I have following comments
table in my app:
comments -------- id INT foreign_id INT model TEXT comment_text TEXT ...
the idea of this table is to store comments for various parts of my app - it can store comments for blog post i.e.:
1|34|blogpost|lorem ipsum...
user picture:
2|12|picture|lorem ipsum...
and so on.
now, is there a way to force FOREIGN KEY constraint on such data?
i.e. something like this in comments table:
FOREIGN KEY (`foreign_id`) REFERENCES blogposts (`id`) -- but only when model='blogpost'
You're attempting to do a design that is called Polymorphic Associations. That is, the foreign key may reference rows in any of several related tables.
But a foreign key constraint must reference exactly one table. You can't declare a foreign key that references different tables depending on the value in another column of your Comments
table. This would violate several rules of relational database design.
A better solution is to make a sort of "supertable" that is referenced by the comments.
CREATE TABLE Commentable ( id SERIAL PRIMARY KEY ); CREATE TABLE Comments ( comment_id SERIAL PRIMARY KEY, foreign_id INT NOT NULL, ... FOREIGN KEY (foreign_id) REFERENCES Commentable(id) );
Each of your content types would be considered a subtype of this supertable. This is analogous to the object-oriented concept of an interface.
CREATE TABLE BlogPosts ( blogpost_id INT PRIMARY KEY, -- notice this is not auto-generated ... FOREIGN KEY (blogpost_id) REFERENCES Commentable(id) ); CREATE TABLE UserPictures ( userpicture_id INT PRIMARY KEY, -- notice this is not auto-generated ... FOREIGN KEY (userpicture_id) REFERENCES Commentable(id) );
Before you can insert a row into BlogPosts
or UserPictures
, you must insert a new row to Commentable
to generate a new pseudokey id. Then you can use that generated id as you insert the content to the respective subtype table.
Once you do all that, you can rely on referential integrity constraints.
In MySQL 5.7 you can have a single polymorphic table AND enjoy something like a polymorphic foreign key!
The caveat is that technically you will need to implement it as multiple FKs on multiple columns (one per each entity that has comments), but the implementation can be limited to the DB side (i.e. you will not need to worry about these columns in your code).
The idea is to use MySQL's Generated Columns:
CREATE TABLE comments ( id INT NOT NULL AUTO_INCREMENT, foreign_id INT, model TEXT, commented_text TEXT, generated_blogpost_id INT AS (IF(model = 'blogpost', foreign_id, NULL)) STORED, generated_picture_id INT AS (IF(model = 'picture', foreign_id, NULL)) STORED, PRIMARY KEY (id) , FOREIGN KEY (`generated_blogpost_id`) REFERENCES blogpost(id) ON DELETE CASCADE, FOREIGN KEY (`generated_picture_id`) REFERENCES picture(id) ON DELETE CASCADE )
You can ignore the generated_*
columns; they will be populated automatically by MySQL as comments are added or modified, and the FKs defined for them will ensure data consistency as expected.
Obviously it would impact both the size requirements and performance, but for some (most?) systems it would be negligible, and a price worth paying for achieving data consistency with a simpler design.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With