Външен ключ за множество таблици и колони?

Не е необходимо да включвате името на артикула и в двете таблици. Това се нарича денормализирано решение. Трябва да го имате само в таблицата с елементи и да се позовавате само на идентификатора, след което ако имате нужда от името също можете да се присъедините към него въз основа на първичния ключ (id). В противен случай е напълно ОК в моя мнение.

CREATE TABLE user(
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  password VARCHAR(20) NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE items(
  i_id INT(11) NOT NULL AUTO_INCREMENT,
  name TINYTEXT NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (i_id)
);

CREATE TABLE user_purchase(
  i_id INT(11) NOT NULL,
  name TINYTEXT NOT NULL,
  id INT(11) NOT NULL,
  FOREIGN KEY (i_id) REFERENCES items(i_id),
  FOREIGN KEY (id) REFERENCES user(id)
);

Понякога, когато производителността е критична, трябва да използвате денормализирани таблици. Може да бъде много по-бързо.

Нормализирането е важно, за да се избегнат различни аномалии. Ако имате таблици в нормална форма на високо ниво, тогава вашите таблици няма да бъдат излишни и няма да имат тези аномалии. Например, ако имате нещо, съхранявано на няколко места, трябва да се грижите, за да поддържате всички излишни данни актуални. Това ви дава шанс да направите това неправилно и в крайна сметка да имате различни аномалии.

Във вашата ситуация наличието на външен ключ ви помага да запазите целостта на данните, но без външен ключ за името бихте могли да имате артикули с имена в покупките, които не присъстват в таблицата с артикули.

Това е един вид аномалия.

Има много видове това, най-добре е да ги избягвате, колкото можете по-дълго.

Прочетете повече тук за аномалиите

В някои случаи трябва да денорамализирате. Така че съхранявайте някои данни излишно поради проблеми с производителността. По този начин можете да спестите някои операции за присъединяване, които биха отнели много време.

Подробности за нормализирането са обхванати от теми с различни нормални форми:NF0, NF1, NF2, NF3 и BCNF

Нормални форми в подробности

За повече подробности относно математическите основи на разлагане без загуби до по-високи нормални форми вижте "Функционални зависимости". Това ще ви помогне да разберете защо можете да запазите идентификаторите "излишни". На практика те са необходими излишни, тъй като имате нужда от тях, за да можете по-късно да възстановите оригиналния набор от данни. Това ще бъде определението за различните нормални форми. Какво ниво на това съкращаване е разрешено?

Функционални зависимости