Foreign key voor meerdere tabellen en kolommen?

U hoeft de itemnaam niet in beide tabellen op te nemen. Dit wordt een gedenormaliseerde oplossing genoemd. Je zou het alleen in de itemstabel moeten hebben en alleen naar de id moeten verwijzen, en als je de naam nodig hebt, kun je er ook aan deelnemen op basis van de primaire sleutel (id). Anders is het helemaal OK in mijn mening.

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)
);

Soms, wanneer de prestaties van cruciaal belang zijn, moet u gedenormaliseerde tabellen gebruiken. Het kan veel sneller.

Normalisatie is belangrijk om verschillende anomalieën te voorkomen. Als je tabellen in een normale vorm op hoog niveau hebt, zullen je tabellen niet overbodig zijn en zullen ze deze anomalieën niet hebben. Als u bijvoorbeeld iets op meerdere locaties heeft opgeslagen, moet u ervoor zorgen dat alle overtollige gegevens up-to-date zijn. Dit geeft je de kans om dit verkeerd te doen en uiteindelijk verschillende anomalieën te krijgen.

In uw situatie helpt het hebben van een externe sleutel u om de gegevensintegriteit te behouden, maar zonder een externe sleutel voor de naam zou u artikelen kunnen hebben met namen in de aankopen die niet in de artikeltabel staan.

Dit is een soort anomalie.

Er zijn veel soorten hiervan, je kunt ze het beste zo lang mogelijk vermijden.

Lees hier meer over anomalieën

In sommige gevallen moet u denormaliseren. Sla sommige gegevens daarom redundant op vanwege prestatieproblemen. Op deze manier kunt u enkele deelname-bewerkingen besparen die veel tijd kunnen kosten.

Details van normalisatie worden behandeld door onderwerpen met verschillende normaalvormen:NF0, NF1, NF2, NF3 en BCNF

Normale formulieren in detail

Voor meer details over de wiskundige grondslagen van lossless ontbinding tot hogere normaalvormen, zie "Functionele afhankelijkheden". Dit gaat u helpen begrijpen waarom u de ID's "redundant" kunt houden. Vrijwel ze zijn noodzakelijke redundantie, omdat je ze nodig hebt om later de originele dataset opnieuw te kunnen opbouwen. Dit wordt de definitie voor de verschillende normaalvormen. Welk niveau van deze redundantie is toegestaan?

Functionele afhankelijkheden