BLOB/TEXT colonne 'bestilling' utilisés dans la spécification de la clé sans clé, longueur

De votre définition ci-dessus, et la verbose monologue dans cette réponse, ci-dessous je vous propose la suite de la révision:

CREATE TABLE IF NOT EXISTS `bestillinger` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `bestilling` TEXT NOT NULL,
  `hashcode` CHAR(32) AS (MD5(bestilling)),  
  `accepted` VARCHAR(255) DEFAULT NULL,
  UNIQUE KEY `id_bestilling` (hashcode,bestilling(333))
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Spécifique à MySQL, la valeur par défaut nombre maximal de caractères pour une seule colonne de la clé d'index est 1000 octets long (767 octets pour les tables InnoDB, sauf si vous avez innodb_large_prefix set). La même longueur limite s'applique à tout indice de préfixe de la clé (les N premiers caractères de type CHAR, VARCHAR, TEXT ou N premiers octets de BINARY, VARBINARY, BLOB). Remarque le caractère contre octet différence; en supposant un caractère UTF-8 et au maximum de 3 octets pour chaque caractère, vous pouvez atteindre cette limite avec un préfixe de colonne d'index de plus de 333 caractères sur un TEXTE ou une colonne de type VARCHAR. Dans la pratique, 333 tend à être un bon max pour moi.

De la même façon dans SQL Server, il y a une limite de 900 octets pour la taille maximale des colonnes de clés d'index.

Mais qui n'utilise que les premiers caractères de votre TEXTE en tant que votre clé, avec l'évidente collisions imminentes.

Dans l'acceptation de réponse, la suggestion est d'utiliser un Index de texte intégral. Un index de texte intégral est spécialement conçu pour la recherche de texte, et il n'a pas-si-bon rendement pour INSÉRER/SUPPRIMER car il maintient un N-gramme sur le vocabulaire de la colonne enregistre et stocke le vecteur résultant. Cela ne peut fonctionner que si toutes les opérations ont été de texte utiliser les fonctions de recherche dans une clause where...mais pas pour un index unique. Il est aussi à la fois une clé primaire et une clé unique définie sur 'id', qui semble redondant ou je m'ennuie de l'intention.

Au lieu de cela, je vous propose un hachage calculée. vous auriez raison de souligner qu'il ya une chance (Paradoxe d'Anniversaire) qu'il y aura une collision avec un hash, donc un index UNIQUE ne suffit pas. Nous allons coupler avec un préfixe de colonne de l'index, comme décrit ci-dessus, pour nous donner la foi en l'unicité.

Je recueillir l'intention de votre colonne ID est de permettre une clé étrangère référençant d'autres tables. Tout à fait exact, mais alors qui serait le plus utile de la clé primaire de cette table. Ainsi, int(11) se réfère à la largeur de l'affichage de la colonne, et non la valeur sous-jacente. J'ai mis un unsigned auto_increment sur 'id' ainsi, afin de clarifier son rôle pour le grand public.

Et cela nous amène à la conception proposée ci-dessus.

Je pense que l'exemple suivant permet de mieux expliquer ce problème.

J'ai eu le problème parce que j'essayais de définir un champ de texte UNIQUE. J'ai résolu le problème en changeant de type de données de messagerie(TEXTE) à l'email(VARCHAR(254)).

mysql> desc users;
+-------------+-------------+------+-----+---------+----------------+
| Field       | Type        | Null | Key | Default | Extra          |
+-------------+-------------+------+-----+---------+----------------+
| id          | int(11)     | NO   | PRI | NULL    | auto_increment |
| fname       | varchar(50) | NO   |     | NULL    |                |
| lname       | varchar(50) | NO   |     | NULL    |                |
| uname       | varchar(20) | NO   |     | NULL    |                |
| email       | text        | NO   |     | NULL    |                |
| contact     | bigint(12)  | NO   |     | NULL    |                |
| profile_pic | text        | NO   |     | NULL    |                |
| password    | varchar(20) | NO   |     | admin   |                |
+-------------+-------------+------+-----+---------+----------------+
8 rows in set (0.00 sec)
mysql> ALTER TABLE users ADD UNIQUE(email);
ERROR 1170 (42000): BLOB/TEXT column 'email' used in key specification without a key length
mysql> 
mysql> ALTER  TABLE users MODIFY email VARCHAR(254);
Query OK, 9 rows affected (0.02 sec)
Records: 9  Duplicates: 0  Warnings: 0
mysql> ALTER TABLE users ADD UNIQUE(email);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0
mysql> desc users;
+-------------+--------------+------+-----+---------+----------------+
| Field       | Type         | Null | Key | Default | Extra          |
+-------------+--------------+------+-----+---------+----------------+
| id          | int(11)      | NO   | PRI | NULL    | auto_increment |
| fname       | varchar(50)  | NO   |     | NULL    |                |
| lname       | varchar(50)  | NO   |     | NULL    |                |
| uname       | varchar(20)  | NO   |     | NULL    |                |
| email       | varchar(254) | YES  | UNI | NULL    |                |
| contact     | bigint(12)   | NO   |     | NULL    |                |
| profile_pic | text         | NO   |     | NULL    |                |
| password    | varchar(20)  | NO   |     | admin   |                |
+-------------+--------------+------+-----+---------+----------------+
8 rows in set (0.00 sec)
mysql>