Performance and model differences between indexed FK and indexed column

Question

I was designing some tables, using MySQL WorkBench, and setting Foreign Keys on some columns, to follow some "correct" design pattern. Then, my boss asked me why I used FK, because they " only cause problems ".

Seeing what does MySQL WorkBench when creating a new FK, it creates the relationship, and an index on it. Like this:

CREATE TABLE `smx_portales-des`.`A1` (
  `idA1` INT NOT NULL,
  `name` VARCHAR(45) NULL,
  PRIMARY KEY (`idA1`));

CREATE TABLE `smx_portales-des`.`A2` (
  `idA2` INT NOT NULL,
  `price` DECIMAL(10,2) NULL,
  `fkA1` INT NULL,
  PRIMARY KEY (`idA2`),
  INDEX `fk_A2_A1_idx` (`fkA1` ASC),
      CONSTRAINT `fk_A2_A1`
  FOREIGN KEY (`fkA1`)
      REFERENCES `smx_portales-des`.`A1` (`idA1`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION);

My boss told me to create table A2 as follows:

  CREATE TABLE `smx_portales-des`.`A2` (
      `idA2` INT NOT NULL,
      `price` DECIMAL(10,2) NULL,
      `fkA1` INT NULL,
      PRIMARY KEY (`idA2`),
      INDEX fk_A2_A1(fkA1));

So, aside from the obvious restriction of FK that only allows values that are on the other table, or NULL s, is there any other performance, stylist, or whatever difference in those models?

EDIT: I know that FKs help in DB data integrity, and that there are some cascade options that help removing/updating childs. Also, that the difference is that in the second model, I'm using an index in a " emulated " FK column. My wonders where more about plausible differences in those two models, like efficiency, size...

Answer 1

Your boss is wrong. And feel free to show him or her this answer.

One key piece of functionality in relational databases is maintaining data integrity. A key part of data integrity is assuring that foreign key relationships are correct.

In your database, that guarantees that a2.fka1 is always referring to a valid column in a1 (or has a NULL value). This is important for people understanding the data, for people writing queries (so rows are not lost inadvertently in joins), and potentially for the optimizer).

The right place to maintain this functionality is in the database. You can try to do it from applications, but the database ensures that the data is correct regardless of data modification operations.

Finally, foreign keys are pretty flexible. You (and your boss) should learn about cascading constraints. They usually implement the functionality needed by an application.

Answer 2

I too currently work somewhere where foreign keys are not used and not enforced. However, i would strongly advise to use them. It looks like your boos has told you to just put an index on the foreign key column instead of actually creating a relationship with a key between the 2 tables.

The second query would probably run faster but without a foreign key relationship you most likely will lose data integrity and increase the possibility of orphaned rows which is something i have seen first hand. By not using keys it is faster to implement and will possibly run faster too but it will create far more problems for the database in the long term. My advice would be to create the key and then use indexes too

Answer 3

All design decisions are trade-offs. The obvious things to trade are performance (time) and space efficiency - but you also want to worry about maintainability and resilience.

From a performance and space efficiency point of view, there's no measurable difference between your options.

@gordonLinoff has already replied regarding data integrity, which is a key aspect of resilience - does your application design make it harder or easier to resist bugs?

Finally, from a maintainability point of view, having a foreign key creates an explicit artefact in your code base, saying data entity a is related to data entity b. This means that future developers don't have to worry about naming conventions, or wether the data is consistent - they can make simple assumptions about your data.

This does come at a small cost - your client code needs to handle specific types of error messages, and you need to wrap your head around the cascade logic, which some people find a little bit of a chore. I personally think that's a small price to pay.