Question

Question:

Is there a way to make the foreign ID point to something more generic than one specific table?

Details:

Often I run into the situation where I have several tables which have nothing to do with each other, but still need a common table (in below examples engine is innodb)

CREATE TABLE IF NOT EXISTS movies
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS books
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS songs
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS news_papers
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS scrolls
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS sumarian_wheat_tablets
(
   id    INT NOT NULL auto_increment,
   name  VARCHAR(100) NOT NULL ,

   PRIMARY KEY(id)
);

Now I want to keep a record of every time each is viewed like so

CREATE TABLE IF NOT EXISTS movie_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES movies ( id ),
   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS book_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES books ( id ),
   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS song_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES songs ( id ),
   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS news_paper_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES news_papers ( id ),
   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS scroll_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES scrolls ( id ),
   PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS sumarian_wheat_tablet_history
(
   id          INT NOT NULL auto_increment,
   foreign_id  INT NOT NULL ,
   view_date   TIMESTAMP DEFAULT now(),

   FOREIGN KEY (foreign_id) REFERENCES sumarian_wheat_tablets ( id ),
   PRIMARY KEY(id)
);

Is there a more correct way to handle such situations without making n new tables? I realize that I can make one history table and copy it over with CREATE TABLE...LIKE... but that still requires making n new tables, plus I have to go in and ALTER the foreign_id.

Answer 1

My first thought is just dump the fk reference and have one history table:

CREATE TABLE history(
   base_table    VARCHAR,
   base_table_id INT,
   view_date     TIMESTAMP DEFAULT now()
);

But I assume you want the fk to maintain the integrity (question: is this really necessary, or can this be worked around?). I guess you could accomplish this by creating a table of “pks in use”. For example:

• create a table “keys” with columns id (autoincrement) and base_table_name
• create a table “movies”, where id is both pk and also a fk to “keys.id” (but not an autoincrement column)
• add a “before insert” trigger to “movies” which inserts a record into “keys” returning the generated id to be used as the id for the “movie” record
• create a history table with a fk to “keys”
• create a “delete” trigger on “movies” which also removes the record from “keys” if you want the integrity maintained, or cascading deletes, etc

So the generated “id” is shared across many tables. There is a school of thought that suggests using a primary key unique across all relations within the database (an “enterprise key”), so it is not unprecedented. Instead of using sequences or autogenerated columns, sometimes a GUID or UUID is used.

This replaces extra history tables with triggers on each base table, which might not be a great thing, depending on your environment. I haven’t done this myself, just throwing some thoughts out there, so take it for what its worth.