I have a database I'm trying to create on SQL and I am trying to connect the relationships together. There are three tables: superhero, power, and superheroPower. The tables superhero and power is a many to many relationship which is represented by the table superheroPower.
Is the syntax below correct for foreign keys between tables (and everything else)? Also, is there any other recommendations on these tables in terms of their setup?
CREATE TABLE superhero( id INT NOT NULL AUTO_INCREMENT,
heroName VARCHAR(255) NOT NULL,
firstName VARCHAR(255),
lastName VARCHAR(255),
firstAppearance DATE,
gender VARCHAR(255),
bio TEXT,
universe VARCHAR(255),
PRIMARY KEY(id)
) ENGINE=InnoDB;
CREATE TABLE power(
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
description TEXT NOT NULL,
PRIMARY KEY(id)
) ENGINE=InnoDB;
CREATE TABLE superheroPower(
superheroID INT,
powerID INT,
PRIMARY KEY(superheroID, powerID),
FOREIGN KEY(superheroID) REFERENCES superhero(id),
FOREIGN KEY(powerID) REFERENCES power(id)
) ENGINE=InnoDB;
Edit[1]: This is a version of SQL code on how I would do it!!
edit[2]:You are able to change null to not null and vise versa depending on if you want a user to move past with out installing the other information. I have never used the Auto_increment before in my sql tables, so for me that is something new I just learned from you
Your design seems on the right track, this is the tables i would have gone with - adding some Indexes for the fields its likely that you will search for and adding the actions needed for the CONSTRAINT keys
Yes, everything there looks okay. But...
A few notes:
We'd use a shorter datatype for the
gender
column; I don't see that we'd need 255 characters to express that. (There is a limit on the maximum size of a row which is enforced.) If there only a few values for that, we'd considerENUM
datatype.We'd also likely add
NOT NULL
constraints on several of those columns, such as heroname, firstname, lastname. We'd also likely addDEFAULT ''
. Sometimes, we really do need to allow NULL values for some reason, but we useNOT NULL
wherever we can.I'm hesitant about the
TEXT
columns. There's nothing wrong with usingTEXT
datatype, but I'm just suspicious that those may be "hiding" some information that might better be stored in additional columns.For the foreign keys, we'd assign a name to the constraints, following the pattern we use, and also likely add
ON UPDATE CASCADE ON DELETE CASCADE
A note about identifiers (table names and column names)
The way we do it, all table name are lower case. (We have a MySQL option set that forces all table names to lower case.) We do this to avoid incompatibility issues for different operating systems/filesystems (some of which are case sensitive, and some are not).
Also, table names are singular. The name of the table names what one row of the table represents. We also don't include
_table
as part of the name.Column names in MySQL are never case sensitive, but we always use lower case for the column names as well. We don't "camelCase" our column names, we use underscore character as separators, e.g.
power_id
vs.powerID
,hero_name
vs.heroName
.FOLLOWUP
My "notes" above aren't specific rules that must be followed; those are just patterns we use.
Following these patterns does not guarantee that we'll have a successful software, but it does help us.
For your reference, I'll show how these tables would look as a "first cut" from our shop, as an illustration of another pattern; this is not "the right way", it's just "a way" that we've settled on as a team.