Ja, da sieht alles in Ordnung aus. Aber...
Ein paar Anmerkungen:
Wir würden einen kürzeren Datentyp für gender verwenden Säule; Ich sehe nicht, dass wir 255 Zeichen brauchen würden, um das auszudrücken. (Es gibt eine Begrenzung der maximalen Größe einer Zeile, die erzwungen wird.) Wenn es dafür nur wenige Werte gibt, würden wir ENUM in Betracht ziehen Datentyp.
Wir würden wahrscheinlich auch NOT NULL hinzufügen Einschränkungen für mehrere dieser Spalten, wie z. B. heroname, firstname, lastname. Wir würden wahrscheinlich auch DEFAULT '' hinzufügen . Manchmal müssen wir aus irgendeinem Grund wirklich NULL-Werte zulassen, aber wir verwenden NOT NULL wo immer wir können.
Beim TEXT bin ich skeptisch Säulen. Es spricht nichts dagegen, TEXT zu verwenden datatype, aber ich habe nur den Verdacht, dass diese einige Informationen "verstecken", die besser in zusätzlichen Spalten gespeichert werden könnten.
Für die Fremdschlüssel würden wir den Einschränkungen einen Namen zuweisen, dem von uns verwendeten Muster folgen, und wahrscheinlich auch ON UPDATE CASCADE ON DELETE CASCADE hinzufügen
CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
Ein Hinweis zu Bezeichnern (Tabellennamen und Spaltennamen)
So wie wir es machen, sind alle Tabellennamen Kleinbuchstaben . (Wir haben einen MySQL-Optionssatz, der alle Tabellennamen auf Kleinschreibung zwingt.) Wir tun dies, um Inkompatibilitätsprobleme für verschiedene Betriebssysteme/Dateisysteme zu vermeiden (von denen einige zwischen Groß- und Kleinschreibung unterscheiden und andere nicht).
Außerdem sind Tabellennamen Einzahl . Der Name der Tabelle benennt eine Zeile der Tabelle darstellt. Wir schließen auch _table nicht ein als Teil des Namens.
Bei Spaltennamen in MySQL wird niemals zwischen Groß- und Kleinschreibung unterschieden, aber wir verwenden auch für die Spaltennamen immer Kleinbuchstaben. Wir verwenden unsere Spaltennamen nicht in "camelCase", sondern verwenden Unterstriche als Trennzeichen, z. power_id vs. powerID , hero_name vs. heroName .
NACHVERFOLGUNG
Meine „Anmerkungen“ oben sind keine spezifischen Regeln, die befolgt werden müssen; das sind nur Muster, die wir verwenden.
Das Befolgen dieser Muster garantiert nicht, dass wir eine erfolgreiche Software haben, aber es hilft uns.
Zu Ihrer Information zeige ich, wie diese Tische als "erster Schnitt" aus unserem Shop aussehen würden, als Illustration eines anderen Musters; das ist nicht "der richtige Weg", es ist nur "ein Weg", auf den wir uns als Team geeinigt haben.
CREATE TABLE superhero
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, hero_name VARCHAR(255) NOT NULL COMMENT ''
, first_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, last_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, first_appearance DATE COMMENT 'date superhero first appeared'
, gender ENUM('female','male','other') COMMENT 'female,male or other'
, biography_text TEXT COMMENT ''
, universe VARCHAR(255) COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY superhero_UX1 (hero_name)
) ENGINE=InnoDB;
CREATE TABLE power
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, name VARCHAR(255) NOT NULL COMMENT ''
, description_text TEXT NOT NULL COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY power_UX1 (name)
) ENGINE=InnoDB;
CREATE TABLE superheropower
( superhero_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref superhero'
, power_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref power'
, PRIMARY KEY(superhero_id, power_id)
, CONSTRAINT FK_superheropower_superhero
FOREIGN KEY(superhero_id) REFERENCES superhero(id)
ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT FK_superheropower_power
FOREIGN KEY (power_id) REFERENCES power(id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
