Sim, tudo lá parece bem. Mas...
Algumas notas:
Usaríamos um tipo de dados mais curto para o
gender coluna; Não vejo que precisaríamos de 255 caracteres para expressar isso. (Há um limite no tamanho máximo de uma linha que é aplicada.) Se houver apenas alguns valores para isso, consideraremos ENUM tipo de dados. Provavelmente também adicionaríamos
NOT NULL restrições em várias dessas colunas, como heroname, firstname, lastname. Provavelmente também adicionaríamos DEFAULT '' . Às vezes, realmente precisamos permitir valores NULL por algum motivo, mas usamos NOT NULL onde pudermos. Estou hesitante sobre o
TEXT colunas. Não há nada de errado em usar TEXT tipo de dados, mas estou apenas desconfiado de que eles possam estar "escondendo" algumas informações que podem ser melhor armazenadas em colunas adicionais. Para as chaves estrangeiras, atribuiríamos um nome às restrições, seguindo o padrão que usamos, e provavelmente também adicionaríamos
ON UPDATE CASCADE ON DELETE CASCADE CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
Uma nota sobre identificadores (nomes de tabelas e nomes de colunas)
Do jeito que fazemos, todos os nomes das tabelas são minúsculas . (Nós temos um conjunto de opções MySQL que força todos os nomes de tabelas para letras minúsculas.) Fazemos isso para evitar problemas de incompatibilidade para diferentes sistemas operacionais/sistemas de arquivos (alguns dos quais diferenciam maiúsculas de minúsculas e outros não).
Além disso, os nomes das tabelas são singulares . O nome da tabela nomeia o que uma linha da tabela representa. Também não incluímos
_table como parte do nome. Os nomes das colunas no MySQL nunca diferenciam maiúsculas de minúsculas, mas sempre usamos letras minúsculas para os nomes das colunas também. Nós não "camelCase" nossos nomes de colunas, usamos caracteres de sublinhado como separadores, por exemplo
power_id vs. powerID , hero_name vs. heroName . ACOMPANHAMENTO
Minhas "notas" acima não são regras específicas que devem ser seguidas; esses são apenas padrões que usamos.
Seguir esses padrões não garante que teremos um software de sucesso, mas nos ajuda.
Para sua referência, vou mostrar como ficariam essas mesas como um "primeiro corte" da nossa loja, como ilustração de outro padrão; isso não "do jeito certo", é apenas "um jeito" que escolhemos como equipe.
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;
