conception de base de données parfaite

Question

Ceci est mon schéma de la table,

ci-dessous am est le schéma pour la fonctionnalité de table de rétroaction, s'il vous plaît donner une bonne suggestion pour la longueur et le sens de dénomination pour la table et ses champs,

s'il vous plaît partager votre suggestion sur le schéma de la table et sa longueur et conventions de nommage.

CREATE TABLE `mytest`.`tbl_feedback` (
`feedback_id` INT(30) NOT NULL AUTO_INCREMENT PRIMARY KEY , 
`first_name` VARCHAR(50) NOT NULL , 
`last_name` VARCHAR(50) NOT NULL , 
`email_id` VARCHAR(150) NOT NULL , 
`comment` TEXT NOT NULL , 
`cur_timestamp` VARCHAR(20) NOT NULL , 
`ipaddress` VARCHAR(20) NOT NULL , 
`status` INT(3) NOT NULL DEFAULT '0' 
) ENGINE = MYISAM ; 

aussi j'ai vu dans ce fil varbinary,

ici ils ont dit l'utilisation varbinary isntead de varchar, pourquoi devrions-nous aller pour varbinary, quel est l'avantage

Answer 1

Essayez de placer les champs de longueur fixe (tels que «statut») avant les champs de longueur variable. Cela ne changera rien à la logique, mais le programme devrait fonctionner un peu plus vite lors de l'accès à ces champs.

Answer 2

Certains champs regardent-ils les pourrait être normalisé .. comme le statut de contrainte de clé étrangère, à une table de statut, et les gens comme une table séparée avec un personid comme un FK. Ensuite, vous pouvez faire des choses cool comme rechercher tous les commentaires par personne, ou supprimer tout par personne, etc

Answer 3

Voici quelques observations:

• Nom de la table « tbl_feedback » - Ceci est une préférence personnelle, mais je supprimerait le préfixe « tbl_ » - Je ne l'ai jamais couru dans un cas où je J'ai trouvé utile d'avoir des préfixes sur les objets de base de données.

• email_id - J'enlève le suffixe "_id". ID est une convention de dénomination commune pour les colonnes clés (primaires ou étrangères), et vous semblez également utiliser cette convention. Dans votre cas, il ne semble pas que email_id soit une clé étrangère, donc juste "email" pourrait être mieux. Cur_timestamp - Un nom comme "created_date" ou "updated_date" peut sembler un peu plus logique. Avec cur_timestamp, il n'est pas vraiment clair à quoi sert la colonne, ou si vous êtes supposé la mettre à jour quand vous mettez à jour l'enregistrement ... etc. De plus, pour cette colonne, il peut être utile d'utiliser un type intégré peut représenter une date, plutôt qu'un varchar. Ipaddress - Juste un nitpick, mais basé sur votre convention de nommage, il pourrait être préférable que ce soit "ip_address". En outre, vous souhaiterez probablement faire de cette colonne au moins 40 caractères ou plus, de sorte que vous puissiez stocker des adresses IPv6 (dans la notation commune). Status: cette colonne pointe-t-elle vers une autre table "status"? Si oui, devrait-il s'agir d'une clé étrangère nommée "status_id"?