Wat is het verschil tussen deze twee SQL-query's?

Ik heb een tabeladres gemaakt met deze SQL-query:

CREATE TABLE `address` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `Street` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `Number` smallint(6) DEFAULT NULL,
  `other_id` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  FOREIGN KEY (`other_id`) REFERENCES `other` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Maar er is ook deze vraag:

CREATE TABLE `address` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `Street` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `Number` smallint(6) DEFAULT NULL,
  `other_id` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `other_id` (`other_id`),
  CONSTRAINT `adress_ibfk_1` FOREIGN KEY (`other_id`) REFERENCES `other` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci$$

en het lijkt erop dat de cabine-query identieke tabellen maakt.

Dus kan iemand mij uitleggen wat deze regel doet:

KEY `other_id` (`other_id`),

en wat is het verschil tussen deze twee lijnen:

  FOREIGN KEY (`other_id`) REFERENCES `other` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
and
  CONSTRAINT `adress_ibfk_1` FOREIGN KEY (`other_id`) REFERENCES `other` (`id`) ON DELETE CASCADE ON UPDATE CASCADE

Als het verschil tussen de laatste twee regels is dat de laatste naam 'adress_ibfk_1' aan de buitenlandse sleutel geeft? Als dat waar is, moet ik het dan doen? Ik bedoel, waarom zou ik buitenlandse sleutels noemen? Heb ik ooit hun naam nodig?

Bedankt ! :)

0
OMG voor jullie allemaal: D Dit is gewoon een domme tafel om mijn vraag te beschrijven ... en ja, ik heb een verkeerd gespeld adres ...
toegevoegd de auteur xx77aBs, de bron
@ f00: nou ik zie niet in waarom het gebruik van bigint op alle tafels een probleem is bij een klein project? Hoe dan ook, welke andere datatypes zou je volgens mij moeten aanpassen? Welke datatypes zou u gebruiken?
toegevoegd de auteur xx77aBs, de bron
@HLGEM: Oh, ik ging ervan uit dat het de locatie was waar een enkel item vrouwenkledij werd bewaard.
toegevoegd de auteur Larry Lustig, de bron
@HLGEM - Tenzij de tabelnamen in het Zweeds zijn :). Maar omdat veldnamen niet in het Zweeds zijn, heb je waarschijnlijk gelijk.
toegevoegd de auteur Mikael Eriksson, de bron
Alle ontwikkelaars in uw project zullen u voor altijd haten als u de naam van de tabel niet corrigeert om het adres correct te spellen.
toegevoegd de auteur HLGEM, de bron
hoeveel adressen denk je dat je zult opslaan in die MASSIVE UNSIGNED BIGINT? Uw andere datatypen moeten ook worden geadresseerd !!
toegevoegd de auteur Jon Black, de bron
toegevoegd de auteur santiagobasulto, de bron

2 antwoord

KEY is a synonym for INDEX, so that is creating an index on the other_id column.

Het enige verschil in de constructie van de externe sleutel is dat de laatste beperking -versie u toestaat de beperking een naam te geven, terwijl de eerste een door het systeem gegenereerde naam krijgt.

Deze naam is te zien in de INFORMATION_SCHEMA TABLE_CONSTRAINTS tafel.

2
toegevoegd

MySQL interpreteert KEY als een index, dus de tweede query maakt een index op de kolom other_id .

Het verschil tussen de twee FK-aangiften is dat u de naam handmatig in de tweede regel instelt. In de eerste regel stelt MySQL automatisch een naam in.
Ze hebben wel namen nodig, maar je hoeft er niet noodzakelijkerwijs bewust van te zijn. Sommige meer geavanceerde RDBMS gebruiken deze om explicieter te zijn wanneer een query een foutmelding geeft.

2
toegevoegd
Dank je !! Maar de eerste query maakt ook een index op kolom other_id. Dus wordt het gecreëerd, zelfs als ik het niet specificeer, net als FK get's it's name?
toegevoegd de auteur xx77aBs, de bron
Dus het is geen regel? Ik bedoel, er zou RDBMS kunnen zijn die niet automatisch een index op FK-kolommen maakt?
toegevoegd de auteur xx77aBs, de bron
xx77aBs: Ik weet het niet zeker, maar MySQL maakt hoogstwaarschijnlijk automatisch een index op FK-kolommen.
toegevoegd de auteur Vincent Savard, de bron