varchar (255) vs tinytext / tinyblob et varchar (65535) vs blob / text

Question

Par définition:

VARCHAR: La gamme de Longueur est de 1 à 255 caractères. VARCHAR les valeurs sont triées et par rapport à de la casse, de la mode, à moins que le BINAIRE mot-clé est donnée. x+1 octets
TINYBLOB, TINYTEXT: UNE GOUTTE ou colonne de TEXTE d'une longueur maximale de 255 (2^8 - 1) caractères x+1 octets

Donc, sur cette base, je creaate le tableau suivant:

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255),
  `lastname` tinytext,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Ou est-il préférable de créer un varchar ou tinytext et pourquoi?

Est-il de même pour:

VARCHAR: La gamme de Longueur > 255 caractères. VARCHAR les valeurs sont triées et par rapport à de la casse, de la mode, à moins que le BINAIRE mot-clé est donnée. x+2 octets
BLOB, le TEXTE d'UNE GOUTTE ou de la colonne de TEXTE d'une longueur maximale de 65535 (2^16 - 1) caractères x+2 octets

Answer 1

DE: http://www.pythian.com/news/7129/text-vs-varchar/

À première vue, ça ressemble à du TEXTE et des VARCHAR pouvez stocker le même de l'information. Cependant, il existe des différences fondamentales entre les chemin des champs de TEXTE et les champs VARCHAR travail, qui sont importants pour prendre en considération.

Standard de type VARCHAR est en fait partie de la norme ISO SQL:2003 standard; Les types de données TEXTE, y compris TINYTEXT, sont non-standard.

Le stockage de TEXTE types de données sont stockées en tant qu'objets distincts à partir des tables et des ensembles de résultats qui les contiennent. Ce stockage est transparent - il n'y a pas de différence dans la façon dont une requête concernant un champ de TEXTE est écrit par rapport à un impliquant un champ de type VARCHAR. Puisque le TEXTE n'est pas stocké dans le cadre d'une ligne, l'extraction de champs de TEXTE nécessite un surcroît de [édité 1/22] surcharge de la mémoire.

Maximum VARCHAR longueur maximale de longueur de ligne de type VARCHAR est limité par le maximum de longueur de ligne d'une table. C'est de 65 535 octets pour la plupart des moteurs de stockage (NDB a une autre valeur maximum de la ligne). Théoriquement, la longueur maximale d'un VARCHAR est de 65 536 octets. Les frais généraux plus loin les limites de l'effectif maximum de la taille d'un VARCHAR.

Le stockage de la longueur d'un champ de type VARCHAR prend 1 octet si le VARCHAR le champ a une longueur maximale de 0 à 255 octets; si elle est supérieure à 255 octets, les frais généraux pour stocker la longueur est de 2 octets. Si le type VARCHAR domaine accepte les valeurs NULL, ce qui ajoute une charge supplémentaire - chaque tableau utilise 1 octet de surcharge pour chaque ensemble de 8 champs qui permettent NULL des valeurs. Si le type VARCHAR est la seule ligne de la table, et ne pas autoriser les valeurs NULL, la longueur maximale autorisée pour le type VARCHAR est 65,532 octets.

Gardez à l'esprit que le nombre de VARCHAR(x) représente le nombre de les personnages, pas le nombre d'octets. Par conséquent, vous pouvez avoir des difficultés à essayer de définir un tableau avec seulement VARCHAR(65532) si le jeu de caractères utilise des caractères multi-octets, tel que UTF-8.

Si vous tentez de définir une valeur VARCHAR qui est plus de permis, vous allez courir dans une erreur comme 1118 ou 1074:

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change

certaines colonnes de TEXTE ou des Gouttes.

ERROR 1074 (42000): Column length too big for column 'col_name' (max=[max number here]); use BLOB or TEXT instead

Maximum de la longueur du TEXTE , La taille maximale d'un TEXTE de type de données dépend du type de TEXTE type de données est utilisé. Car ils sont stockés comme des objets, la seule surcharge de ligne dans la table de l'objet est un pointeur (8 ou 16 octets). Voici une liste d'au maximum la longueur du TEXTE, et la les frais généraux (dans l'objet de TEXTE):

TINYTEXT – up to 255 bytes, 1 byte overhead

TEXT – up to 64 Kb, 2 bytes overhead

MEDIUMTEXT – up to 16 Mb, 3 bytes overhead

LONGTEXT – up to 4 Gb, 4 bytes overhead

Les valeurs par DÉFAUT de MySQL ne permet pas de TEXTE types de données ont une valeur par défaut différente de NULL. Les champs VARCHAR sont autorisés à être créé avec une valeur par DÉFAUT.

Conclusions en Raison du stockage des implications, il est préférable d'utiliser VARCHAR au lieu de TINYTEXT.

Si vous avez besoin d'avoir une valeur par DÉFAUT qui n'est pas NULL, vous devez utiliser VARCHAR (ou CHAR).

Si vous avez besoin de stocker des chaînes de plus d'environ 64 Ko, utilisez MEDIUMTEXT ou LONGTEXT. VARCHAR ne peut pas en charge le stockage de valeurs grand.

Assurez-vous que vous êtes conscient des effets d'un multi-byte character set. VARCHAR(255) magasins de 255 caractères, ce qui peut être plus de 255 octets.

Answer 2

Dans ce cas - varchar , c'est mieux.

Notez que varchar peut être de 1 à 65535 caractères.

Les valeurs dans des colonnes VARCHAR sont des chaînes de longueur variable. La longueur peut être défini comme une valeur de 0 à 255 avant MySQL 5.0.3, et de 0 à 65 535 en 5.0.3 et les versions ultérieures. La longueur maximale réelle d'un VARCHAR dans MySQL 5.0.3 et, plus tard, est soumise à la taille maximale de ligne (65 535 octets, qui est partagé entre toutes les colonnes) et le jeu de caractères utilisé. Voir La Section E. 7.4, "Table Column-Count Ligne et Limites de Taille".

Les Blobs sont enregistrés dans une section distincte dans le fichier.
Ils ont besoin d'un fileread à inclure dans les données.
Pour cette raison, varchar est récupéré beaucoup plus rapidement.

Si vous avez un gros blob que vous accéder rarement, qu'un blob a plus de sens.
Stocker les données blob dans un document distinct (partie de la) fichier permet à votre cœur de fichier de données à être plus petits et ainsi être récupérés plus rapidement.