Maison >base de données >tutoriel mysql >Série d'apprentissage MySQL 3 : Types de données
Série d'apprentissage MySQL 3 : Types de données
- 黄舟original
- 2016-12-28 17:38:312708parcourir
Le type de données BLOB dans MYSQL
BLOB est un gros objet binaire utilisé pour stocker des quantités variables de données. Il existe 4 types de BLOB : TinyBlob, Blob, MediumBlob, LongBlob
La seule différence entre ces types est la taille maximale du fichier stocké.
Taille du type des quatre types BLOB de MySQL (unité : octets)
TinyBlob maximum 255
Blob maximum 65K
MediumBlob maximum 16M
Les colonnes LongBlob Maximum 4G
BLOB stockent des chaînes binaires (chaînes d'octets) ; les colonnes TEXT stockent des chaînes non binaires (chaînes de caractères).
Les colonnes BLOB n'ont pas de jeu de caractères, et le tri et les comparaisons sont basés sur la valeur numérique des octets de valeur de la colonne ; les colonnes TEXT ont un jeu de caractères et les valeurs sont triées et comparées en fonction du caractère. set
Les BLOB sont des chaînes binaires, TEXT est une chaîne non binaire, les deux peuvent stocker de grandes quantités d'informations. BLOB stocke principalement des images, des informations audio, etc.
tandis que TEXT ne peut stocker que des fichiers texte.
SQLSERVER
SQLSERVER n'a pas de type de données BLOB, seulement un type de données d'objet volumineux (BLOB) :
text,ntext,image,nvarchar(max),varchar Types de données (max), varbinary (max) et xml
Les données de ces types de données sont stockées dans des pages de données de type LOB
Type de colonne
11.1.1. Aperçu des types numériques
Ce qui suit est un aperçu des types de colonnes numériques. Voir Section 11.2, « Types numériques » pour plus de détails. Pour connaître les exigences de stockage des colonnes, consultez la Section 11.5, « Exigences de stockage des types de colonnes ».
M indique la largeur d'affichage maximale. La largeur d’affichage effective maximale est de 255. La largeur d'affichage n'a rien à voir avec la taille de stockage ou la plage de valeurs contenues dans le type, comme décrit dans la Section 11.2, « Types numériques ».
Si ZEROFILL est spécifié pour une colonne numérique, MySQL ajoute automatiquement l'attribut UNSIGNED à la colonne.
SERIAL est un alias pour BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE.
Dans les définitions de colonnes entières, SERIAL DEFAULT VALUE est un alias pour NOT NULL AUTO_INCREMENT UNIQUE.
Attention : Il doit être clair que lors de l'utilisation du signe moins entre des valeurs entières (dont l'une est de type UNSIGNED), le résultat n'est pas signé. Voir Section 12.8, « Fonctions et opérateurs de diffusion ».
· BIT[(M)]
Type de champ de bits. M représente le nombre de bits par valeur, allant de 1 à 64. Si M est omis, la valeur par défaut est 1.
·TINYINT[(M)] [UNSIGNED] [ZEROFILL]
Un très petit entier. La plage signée est de -128 à 127. La plage non signée va de 0 à 255.
· BOOL, BOOLEAN
est un synonyme de TINYINT(1). Une valeur de zéro est considérée comme fausse. Les valeurs non nulles sont considérées comme vraies.
À l'avenir, un traitement complet de type booléen sera introduit selon le standard SQL.
· SMALLINT[(M)] [UNSIGNED] [ZEROFILL]
Petit entier. La plage signée va de -32768 à 32767. La plage non signée va de 0 à 65 535.
· MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]
Entier de taille moyenne. La plage signée va de -8388608 à 8388607. La plage non signée va de 0 à 16777215.
· INT[(M)] [UNSIGNED] [ZEROFILL]
Un entier de taille normale. La plage signée va de -2147483648 à 2147483647. La plage non signée va de 0 à 4294967295.
· INTEGER[(M)] [UNSIGNED] [ZEROFILL]
C'est un synonyme de INT.
· BIGINT[(M)] [UNSIGNED] [ZEROFILL]
Grand entier. La plage signée va de -9223372036854775808 à 9223372036854775807. La plage non signée va de 0 à 18446744073709551615.
Ce qui suit doit être clair pour la colonne BIGINT :
o Utilisez des valeurs BIGINT ou DOUBLE signées pour toutes les opérations arithmétiques, donc à l'exception des fonctions binaires, aucune valeur supérieure à 9223372036854775807 (63 bits) doivent être utilisés Signé BIG INTEGER ! Si vous faites cela, les derniers chiffres du résultat peuvent être erronés, en raison d'erreurs d'arrondi lors de la conversion des valeurs BIGINT en DOUBLE.
MySQL peut gérer BIGINT dans les situations suivantes :
§ Lors de l'utilisation d'entiers pour stocker de grandes valeurs non signées dans une colonne BIGINT.
§ Dans MIN(col_name) ou MAX(col_name), où col_name fait référence à la colonne BIGINT.
§ Lors de l'utilisation d'opérateurs ( , -, *, etc.) et les deux opérandes sont des entiers.
o Il est toujours possible d'utiliser une chaîne pour contenir une valeur entière stricte dans une colonne BIGINT. Dans ce cas, MySQL effectue une conversion chaîne en nombre, et aucune représentation double précision n'existe entre les deux.
o Les opérateurs - et * utilisent l'algorithme BIGINT lorsque les deux opérandes sont des valeurs entières. Cela montre que si vous multipliez deux grands entiers (ou à partir d'une fonction qui renvoie un entier), vous obtiendrez des résultats inattendus lorsque le résultat est supérieur à 9223372036854775807.
· FLOAT[(M,D)] [UNSIGNED] [ZEROFILL]
Petit nombre à virgule flottante (simple précision). Les valeurs autorisées sont -3.402823466E 38 à -1.175494351E-38, 0 et 1.175494351E-38 à 3.402823466E 38. Il s'agit de limites théoriques, basées sur les normes IEEE. La portée réelle peut être légèrement inférieure en fonction du matériel ou du système d'exploitation.
M est le nombre de décimales, D est le nombre de chiffres après la virgule. Si M et D sont omis, la valeur est enregistrée selon les limitations autorisées par le matériel. Les nombres à virgule flottante simple précision sont précis à environ 7 décimales près.
Si UNSIGNED est spécifié, les valeurs négatives ne sont pas autorisées.
Vous pouvez rencontrer des problèmes inattendus en utilisant des nombres à virgule flottante car tous les calculs dans MySQL sont effectués avec une double précision. Voir Section A.5.7, « Résolution des problèmes liés aux lignes sans correspondance ».
· DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL]
Nombre à virgule flottante de taille normale (double précision). Les valeurs autorisées sont de -1,7976931348623157E 308 à -2,2250738585072014E-308, 0 et 2,2250738585072014E-308 à 1,7976931348623157E 308. Il s'agit de limites théoriques, basées sur les normes IEEE. La portée réelle peut être légèrement inférieure en fonction du matériel ou du système d'exploitation.
M est le nombre total de chiffres décimaux et D est le nombre de chiffres après la virgule. Si M et D sont omis, la valeur est enregistrée selon les limitations autorisées par le matériel. Les nombres à virgule flottante double précision sont précis à environ 15 décimales près.
Si UNSIGNED est spécifié, les valeurs négatives ne sont pas autorisées.
· DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)]
[UNSIGNED] [ZEROFILL]
sont des synonymes de DOUBLE . Sauf : Si le mode serveur SQL inclut l'option REAL_AS_FLOAT, REAL est un synonyme de FLOAT plutôt qu'un synonyme de DOUBLE.
· FLOAT(p) [UNSIGNED] [ZEROFILL]
Numéro à virgule flottante. p représente la précision (exprimée en bits), mais MySQL utilise uniquement cette valeur pour déterminer si le type de données de la colonne de résultat est FLOAT ou DOUBLE. Si p est compris entre 0 et 24, le type de données devient FLOAT sans valeur M ou D. Si p est compris entre 25 et 53, le type de données devient DOUBLE sans valeur M ou D. La plage de colonnes résultante est la même que celle des types de données FLOAT simple précision ou DOUBLE double précision décrits plus haut dans cette section.
La syntaxe FLOAT(p) est compatible avec ODBC.
· DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]
Nombre à virgule fixe "strict" compressé. M est le nombre total de décimales (précision) et D est le nombre de chiffres après la virgule (échelle). Le point décimal et le signe '-' (pour les nombres négatifs) ne sont pas inclus dans M. Si D est 0, la valeur n’a pas de point décimal ni de partie fractionnaire. Le nombre maximum de chiffres (M) dans un entier DECIMAL est 65. Le nombre maximum de chiffres décimaux (D) pris en charge est de 30. Si D est omis,
est par défaut 0. Si M est omis, la valeur par défaut est 10.
Si UNSIGNED est spécifié, les valeurs négatives ne sont pas autorisées.
Les calculs de base pour toutes les colonnes DECIMAL ( , -, *, /) sont effectués avec 65 bits de précision.
· DEC[(M[,D])] [NON SIGNÉ] [ZEROFILL], NUMERIC[(M[,D])]
[NON SIGNÉ] [ZEROFILL], FIXED[(M[, D])] [UNSIGNED] [ZEROFILL]
est un synonyme de DECIMAL. Les synonymes FIXES s'appliquent pour la compatibilité avec d'autres serveurs.
11.1.2. Présentation des types de date et d'heure
Cette section fournit une discussion complète sur les types de colonnes temporaires. Pour plus de détails, consultez la Section 11.3, « Types de date et d'heure ». Pour connaître les exigences de stockage des colonnes, consultez la Section 11.5, « Exigences de stockage des types de colonnes ».
·DATE
Date. La plage prise en charge va de « 1000-01-01 » à « 9999-12-31 ». MySQL affiche les valeurs DATE au format « AAAA-MM-JJ », mais permet d'attribuer des valeurs aux colonnes DATE à l'aide de chaînes ou de nombres.
· DATETIME
Une combinaison de date et d'heure. La plage prise en charge va de « 1000-01-01 00:00:00 » à « 9999-12-31 23:59:59 ». MySQL affiche les valeurs DATETIME au format « AAAA-MM-JJ HH:MM:SS », mais permet d'utiliser des chaînes ou des nombres pour attribuer des valeurs aux colonnes DATETIME.
· TIMESTAMP[(M)]
Horodatage. La plage va de « 1970-01-01 00:00:00 » à 2037.
La colonne TIMESTAMP est utilisée pour enregistrer la date et l'heure lors des opérations INSERT ou UPDATE. Si vous n'attribuez aucune valeur, la première colonne TIMESTAMP du tableau est automatiquement définie sur la date et l'heure de l'opération la plus récente. Vous pouvez également définir la colonne TIMESTAMP sur la date et l'heure actuelles en attribuant une valeur NULL.
La valeur TIMESTAMP est renvoyée et affichée sous forme de chaîne au format 'AAAA-MM-JJ HH:MM:SS'. La largeur d'affichage est fixée à 19 caractères. Si vous souhaitez obtenir une valeur numérique, ajoutez 0 à la colonne TIMESTAMP.
Remarque : Le format TIMESTAMP utilisé avant MySQL 4.1 n'est pas pris en charge dans MySQL 5.1 ; consultez le manuel de référence MySQL 4.1 pour plus d'informations sur l'ancien format.
· HEURE
heure. La plage va de « -838:59:59 » à « 838:59:59 ». MySQL affiche les valeurs TIME au format « HH:MM:SS » mais permet d'attribuer des valeurs aux colonnes TIME à l'aide de chaînes ou de nombres.
· ANNÉE[(2|4)]
Année au format à deux chiffres ou à quatre chiffres. La valeur par défaut est le format à quatre chiffres. Au format à quatre chiffres, les valeurs autorisées sont 1901 à 2155 et 0000. Au format à deux chiffres, les valeurs autorisées vont de 70 à 69, représentant les années 1970 à 2069. MySQL affiche les valeurs ANNÉE au format AAAA, mais permet d'utiliser des chaînes ou des nombres pour attribuer des valeurs aux colonnes ANNÉE.
11.1.3. Présentation des types de chaînes
Cette section fournit une discussion complète sur les types de colonnes de chaînes. Voir Section 11.4, « Type de chaîne » pour plus de détails. Pour connaître les exigences de stockage des colonnes, consultez la Section 11.5, « Exigences de stockage des types de colonnes ».
Dans certains cas, MySQL peut changer une colonne de chaîne en un type différent de celui donné dans l'instruction CREATE TABLE ou ALTER TABLE. Voir la Section 13.1.5.1, « Modifications des spécifications de la colonne silencieuse ».
Le type de données chaîne MySQL 5.1 inclut certaines fonctionnalités qui n'étaient pas disponibles dans les versions antérieures à MySQL 4.1 :
· Les définitions de colonnes pour de nombreux types de données chaîne peuvent inclure l'attribut CHARACTER SET qui spécifie le caractère définies, des règles de relecture peuvent également être incluses. (CHARSET est un synonyme de CHARACTER SET). Ces propriétés s'appliquent aux types CHAR, VARCHAR, TEXT, ENUM et SET. Par exemple :
Cette définition de table crée une colonne nommée c1, avec un jeu de caractères utf8 et le classement par défaut pour ce jeu de caractères, et une colonne nommée La colonne de c2 et le jeu de caractères latin1 et les règles de classement binaire de ce jeu de caractères. Les règles de classement binaire ne sont pas sensibles à la casse.
· MySQL 5.1 interprète les spécifications de longueur dans les définitions de colonnes de caractères en unités de caractères. (Certaines versions précédentes de MySQL interprétaient les longueurs en octets).
· Pour les types CHAR, VARCHAR et TEXT, l'attribut BINARY peut attribuer les règles de classement du jeu de caractères de colonne à la colonne.
· Les colonnes de caractères sont triées et comparées en fonction du jeu de caractères attribué à la colonne. Dans les versions précédentes, le tri et la comparaison étaient basés sur les règles de classement du jeu de caractères du serveur. Pour les colonnes CHAR et VARCHAR, vous pouvez déclarer la colonne avec l'attribut BINARY afin que les règles de tri et de classement utilisent la valeur actuelle du code de caractère plutôt que l'ordre lexical.
Pour la prise en charge des jeux de caractères dans MySQL 5.1, voir Chapitre 10 : Prise en charge des jeux de caractères.
· [NATIONAL] CHAR(M) [BINARY| ASCII | UNICODE]
Chaîne de longueur fixe, complétée par des espaces à droite lorsqu'elle est enregistrée à la longueur spécifiée. M représente la longueur de la colonne. La plage de M est comprise entre 0 et 255 caractères.
Remarque : les espaces de fin sont supprimés lors de la récupération des valeurs CHAR.
Si vous souhaitez définir la longueur d'un CHAR sur une valeur supérieure à 255, l'instruction CREATE TABLE ou ALTER TABLE exécutée échouera et provoquera une erreur :
CHAR est l'abréviation de CHARACTER. NATIONAL CHAR (ou sa forme abrégée équivalente NCHAR) est la méthode SQL standard permettant de définir qu'une colonne CHAR doit utiliser le jeu de caractères par défaut. C'est la valeur par défaut dans MySQL.
L'attribut BINARY est l'abréviation de la règle de classement binaire pour le jeu de caractères de colonne spécifié. Le tri et les comparaisons sont basés sur des valeurs de caractères numériques.
Le type de colonne CHAR BYTE est un alias de CHAR BINARY. Ceci afin de garantir la compatibilité.
Vous pouvez spécifier des attributs ASCII pour CHAR. Il alloue le jeu de caractères latin1.
Vous pouvez spécifier l'attribut UNICODE pour CHAR. Il alloue le jeu de caractères ucs2.
MySQL permet la création de colonnes de type CHAR(0). Ceci est principalement destiné à la compatibilité avec les anciennes versions d'applications qui doivent avoir une colonne mais n'utilisent pas réellement la valeur. C'est aussi bien quand on a besoin d'une colonne qui ne peut prendre que deux valeurs : une colonne CHAR(0) non définie comme NOT NULL ne prend qu'un bit et ne peut prendre que les valeurs NULL et " (chaîne vide).
· CHAR
C'est un synonyme de CHAR(1). [NATIONAL] VARCHAR(M) [BINARY]
M représente la longueur maximale de la colonne M va de 0 à. 65 535 (La longueur réelle maximale d'un VARCHAR est déterminée par la taille de la ligne la plus longue et le jeu de caractères utilisé. La longueur effective maximale est de 65 532 octets) Remarque : conformité à la spécification SQL standard MySQL 5.1 et ne supprime pas les espaces de fin des valeurs VARCHAR. .
VARCHAR est l'abréviation de caractère VARYING.
L'attribut BINARY est l'abréviation de classement binaire du jeu de caractères de la colonne spécifiée. >VARCHAR est enregistré avec un préfixe de longueur d'un ou deux octets. Si la longueur déclarée de la colonne VARCHAR est supérieure à 255, le préfixe de longueur est de deux octets. 🎜>· BINARY(M)
Le. Le type BINARY est similaire au type CHAR, mais contient une chaîne d'octets binaires au lieu d'une chaîne non binaire
· VARBINARY(M)
Le type VARBINARY est similaire au type VARCHAR, mais contient des chaînes d'octets binaires au lieu de chaînes non binaires TINYBLOB
Une colonne BLOB d'une longueur maximale de 255 (28-1) octets
· TINYTEXT
. Colonne TEXTE d'une longueur maximale de 255 (28-1) caractères
· BLOB[(M)]
Une colonne BLOB de 65 535 (216-1) octets. 🎜>
peut recevoir une longueur facultative M de ce type. Si elle est donnée, MySQL crée la colonne aussi minimale que possible mais suffisamment grande pour contenir une valeur de type BLOB
· TEXT[. (M)]
Une colonne TEXT d'une longueur maximale de 65 535 (216-1) caractères
peut recevoir une longueur facultative. M. MySQL crée la colonne comme le plus petit type de TEXT. qui est suffisamment grand pour accueillir des valeurs de M caractères longs
Une colonne BLOB d'une longueur maximale de 16 777 215 (224–1) octets
· MEDIUMTEXT
. Colonne TEXTE d'une longueur maximale de 16 777 215 (224–1) caractères, colonne BLOB de 232–1) octets. La longueur effective maximale (autorisée) d'une colonne LONGBLOB dépend de la taille maximale du paquet configurée dans le protocole client/serveur et de la mémoire disponible.
· LONGTEXT
Une colonne TEXTE d'une longueur maximale de 4 294 967 295 ou 4 Go (232-1) caractères. La longueur effective maximale (autorisée) d'une colonne LONGTEXT dépend de la taille maximale du paquet configurée dans le protocole client/serveur et de la mémoire disponible.
· ENUM('value1', 'value2',…)
Type d'énumération. Une chaîne qui ne peut avoir qu'une seule valeur, choisie parmi les colonnes de valeurs 'valeur1', 'valeur2', ..., NULL ou la "valeur d'erreur" spéciale. La colonne ENUM peut avoir jusqu'à 65 535 valeurs ENUM distinctes. sont utilisés en interne Représentation entière.
· SET('value1','value2',…)
Un objet chaîne peut avoir zéro ou plusieurs valeurs, chaque valeur doit provenir d'une valeur de colonne. 'value1', 'value2', ... Les colonnes SET peuvent avoir jusqu'à 64 membres. Les valeurs SET sont représentées en interne par des entiers
11.2. 🎜>MySQL prend en charge tous les types de données numériques SQL standard. Ces types incluent les types de données numériques stricts (INTEGER, SMALLINT, DECIMAL et NUMERIC) et les types de données numériques approximatifs (FLOAT, REAL et DOUBLE PRECISION). synonyme de INTEGER, et le mot-clé DEC est. Synonymes pour DECIMAL
Le type de données BIT stocke les valeurs des champs de bits et prend en charge les tables MyISAM, MEMORY, InnoDB et BDB. Conformément au standard SQL, MySQL prend également en charge les types entiers TINYINT, MEDIUMINT et BIGINT. Le tableau ci-dessous montre le stockage et la plage requis pour chaque type entier
Type Octets Valeur minimale Valeur maximale
(Signé/Non signé) ( Signé/non signé)
TINYINT 1 -128 127
0 255
SMALLINT 2 -32768 32767
0 65535
MEDIUMINT 3 -8388608 8388607
INT 4 -2147483648 2147483647
0 4294967295
BIGINT 8 -9223372036854775808 9223372036854775807
0 18446744073709551615
MySQL prend également en charge l'option de spécifier la largeur d'affichage d'une valeur entière entre parenthèses après le mot-clé type (par exemple, INT(4)). La spécification facultative de la largeur d’affichage est utilisée pour remplir la largeur à partir de la gauche lorsque la largeur d’affichage est inférieure à la largeur de colonne spécifiée.
La largeur d'affichage ne limite pas la plage de valeurs pouvant être enregistrées dans la colonne, ni l'affichage des valeurs qui dépassent la largeur spécifiée de la colonne.
Lorsqu'ils sont utilisés en combinaison avec l'attribut étendu facultatif ZEROFILL, les espaces supplémentaires par défaut sont remplacés par des zéros. Par exemple, pour une colonne déclarée comme INT(5) ZEROFILL, la valeur 4 est récupérée sous la forme 00004. Veuillez noter que si vous stockez une valeur dans une colonne entière qui dépasse la largeur affichée, MySQL rencontrera des problèmes lors de la génération de tables temporaires pour des jointures complexes, car dans ces cas, MySQL pense que les données tiendront dans la largeur de colonne d'origine.
Tous les types entiers peuvent avoir un attribut facultatif (non standard) UNSIGNED. Les valeurs non signées peuvent être utilisées lorsque vous souhaitez autoriser uniquement les nombres non négatifs dans une colonne et que la colonne nécessite une plage numérique supérieure plus grande.
Les types flottants et à virgule fixe peuvent également être NON SIGNÉS. Pour un même type de nombre, cette propriété empêche l'enregistrement de valeurs négatives dans la colonne. Cependant, contrairement aux types entiers, la plage supérieure des valeurs de colonne reste inchangée.
Si ZEROFILL est spécifié pour une colonne numérique, MySQL ajoute automatiquement l'attribut UNSIGNED à la colonne.
Pour les types de colonnes à virgule flottante, les valeurs simple précision utilisent 4 octets et les valeurs double précision utilisent 8 octets dans MySQL.
Le type FLOAT est utilisé pour représenter des types de données numériques approximatifs. La norme SQL vous permet éventuellement de spécifier la précision en bits (mais pas en plages exponentielles) entre parenthèses après le mot-clé FLOAT. MySQL prend également en charge des spécifications de précision facultatives qui sont utilisées uniquement pour déterminer la taille de stockage. La précision de 0 à 23 correspond à la simple précision de 4 octets de la colonne FLOAT. Les précisions de 24 à 53 correspondent à la double précision sur 8 octets de la colonne DOUBLE.
MySQL permet l'utilisation de syntaxe non standard : FLOAT(M,D) ou REAL(M,D) ou DOUBLE
PRECISION(M,D). Ici, "(M,D)" signifie que la valeur affiche un total d'entiers à M chiffres, où les chiffres D sont situés après la virgule décimale. Par exemple, une colonne définie comme FLOAT(7,4) pourrait être affichée sous la forme -999,9999. MySQL arrondit la valeur lors de sa sauvegarde, donc si vous insérez 999.00009 dans la colonne FLOAT(7,4), le résultat approximatif est 999.0001.
MySQL traite DOUBLE comme synonyme de DOUBLE PRECISION (extension non standard). MySQL traite également REAL comme synonyme de DOUBLE PRECISION (extension non standard) sauf si le mode serveur SQL inclut l'option REAL_AS_FLOAT.
Pour garantir la plus grande portabilité possible, le code qui nécessite le stockage de valeurs de données numériques approximatives doit utiliser FLOAT ou DOUBLE PRECISION, sans spécifier de précision ou de nombre de chiffres.
Les types DECIMAL et NUMERIC sont traités comme le même type dans MySQL. Ils sont utilisés pour contenir des valeurs qui doivent être d'une précision exacte, telles que des données monétaires. Lorsque vous déclarez une colonne de ce type, vous pouvez (et vous le faites généralement) spécifier la précision et l'échelle par exemple :
Dans cet exemple, 5 correspond à la précision et 2 à l'échelle. La précision indique combien de chiffres peuvent être enregistrés dans la valeur et l'échelle indique combien de chiffres peuvent être enregistrés après la virgule décimale.
Enregistrez les valeurs DECIMAL et NUMÉRIQUE au format binaire dans MySQL 5.1.
Le SQL standard exige que la colonne salaire puisse contenir n'importe quelle valeur avec 5 chiffres entiers et deux décimales. Par conséquent, la plage de valeurs pouvant être enregistrées dans la colonne salaire dans ce cas va de -999,99 à 999,99.
En SQL standard, la syntaxe DECIMAL(M) est équivalente à DECIMAL(M,0). De même, la syntaxe DECIMAL est équivalente à DECIMAL(M,0) et la valeur de M peut être déterminée par calcul. Les formes variables de types de données DECIMAL et NUMERIC sont prises en charge dans MySQL
5.1. La valeur par défaut de M est 10.
Le nombre maximum de chiffres pour un DECIMAL ou un NUMERIC est de 65, mais la plage réelle d'une colonne DECIMAL ou NUMERIC spécifique est limitée par la précision ou l'échelle de la colonne spécifique. Si une telle colonne se voit attribuer une valeur comportant plus de chiffres après la virgule que ce qui est autorisé par l'échelle spécifiée, la valeur est convertie selon cette échelle. (L'opération spécifique dépend du système d'exploitation, mais généralement les résultats sont tronqués au nombre de chiffres autorisé).
Le type de données BIT peut être utilisé pour enregistrer les valeurs des champs de bits. Le type BIT(M) permet le stockage de valeurs M-bit. M va de 1 à 64.
Pour spécifier une valeur de bit, vous pouvez utiliser le symbole b'value'. value est une valeur binaire écrite avec 0 et 1. Par exemple, b'111' et b'100000000' représentent respectivement 7 et 128. Voir Section 9.1.5, « Valeurs des champs de bits ».
Si la longueur de la valeur attribuée à la colonne BIT(M) est inférieure à M bits, complétez le côté gauche de la valeur avec des 0. Par exemple, attribuer une valeur b'101' à la colonne BIT(6) a le même effet que attribuer b'000101'.
Lorsque vous souhaitez enregistrer une valeur dans une colonne numérique qui dépasse la plage autorisée de la colonne, le fonctionnement de MySQL dépend du mode SQL en vigueur à ce moment-là. Si le mode n'est pas défini, MySQL coupe la valeur au point final correspondant de la plage et enregistre la valeur coupée. Cependant, si le mode est défini sur traditionnel (« mode strict »), les valeurs hors limites seront rejetées avec une erreur et les insertions échoueront selon les normes SQL. Voir Section 5.3.2, « Mode SQL Server ».
Si la colonne INT est UNSIGNED, la plage de colonnes a la même taille, mais ses extrémités passent à 0 et 4294967295. Si vous essayez de sauvegarder -9999999999 et 9999999999, les valeurs enregistrées dans la colonne en mode non strict sont 0 et 4294967296.
Si la valeur attribuée dans une colonne à virgule flottante ou à virgule fixe dépasse la plage spécifiée par la précision et l'échelle spécifiées (ou par défaut), MySQL enregistre la valeur représentant le point final correspondant de la plage dans un format non strict. mode.
Lorsque MySQL ne fonctionne pas en mode strict, les conversions dues à un écrêtage seront signalées sous forme d'avertissements pour les instructions ALTER TABLE, LOAD DATA INFILE, UPDATE et INSERT multi-lignes. Lorsque MySQL fonctionne en mode strict, ces instructions échoueront et certaines ou toutes les valeurs ne seront pas insérées ou modifiées, selon que la table est transactionnelle et d'autres facteurs. Voir Section 5.3.2, « Mode SQL Server » pour plus de détails.
11.3.Types de date et d'heure
11.3.1. Types DATETIME, DATE et TIMESTAMP 11.3.2. Type TIME 11.3.3. Type YEAR 11.3.4 et types de date
Les types DATE et heure représentant les valeurs de temps sont. DATETIME, DATE, TIMESTAMP, TIME et YEAR. Chaque type d'heure a une plage de valeurs valides et une valeur "zéro", qui est utilisée lors de la spécification d'une valeur illégale que MySQL ne peut pas représenter. Le type TIMESTAMP possède des fonctionnalités propriétaires de mise à jour automatique, qui seront décrites plus loin.
MySQL donnera un avertissement ou une erreur si vous essayez d'insérer une date illégale. Vous pouvez utiliser le mode SQL ALLOW_INVALID_DATES pour permettre à MySQL d'accepter certaines dates, telles que « 1999-11-31 ». Utile lorsque vous souhaitez enregistrer une valeur « éventuellement erronée » que l'utilisateur a spécifiée dans la base de données (par exemple, dans un formulaire Web) pour un traitement ultérieur. Dans ce mode, MySQL vérifie uniquement que la plage des mois est comprise entre 0 et 12 et que la plage des jours est comprise entre 0 et 31. Ces plages peuvent inclure zéro car MySQL permet d'enregistrer le jour/mois et les dates où le jour est zéro dans une colonne DATE ou DATETIME. Ceci est utile lorsqu'une application doit enregistrer un anniversaire dont vous ne connaissez pas la date exacte. Dans ce cas, enregistrez simplement la date sous « 1999-00-00 » ou « 1999-01-00 ». Les fonctions qui nécessitent une date complète telle que DATE_SUB() ou DATE_ADD ne donneront pas de résultats corrects si vous enregistrez une telle date. (Si vous ne souhaitez pas que des zéros apparaissent dans la date, vous pouvez utiliser le mode SQL NO_ZERO_IN_DATE).
MySQL permet également d'enregistrer '0000-00-00' comme "pseudo date" (si le mode SQL NO_ZERO_DATE n'est pas utilisé). C'est plus pratique dans certaines situations que d'utiliser des valeurs NULL (et les données et les index prennent moins de place).
Définissez la variable système sql_mode sur la valeur de mode correspondante pour savoir plus clairement quel type de dates vous souhaitez que MySQL prenne en charge. Voir Section 5.3.2, « Mode SQL Server ».
Les points suivants doivent être gardés à l'esprit lorsque vous travaillez avec des types de date et d'heure :
· MySQL récupère les valeurs d'un type de date ou d'heure donné dans un format de sortie standard, mais il fait son Il est préférable d'interpréter chaque valeur que vous spécifiez. Un format de valeur d'entrée (par exemple, lorsque vous spécifiez une valeur affectée ou comparée à un type de date ou d'heure). Seuls les formats décrits dans les sections suivantes sont pris en charge. Vous êtes censé fournir des valeurs valides. Des résultats inattendus peuvent survenir si vous utilisez des valeurs dans d'autres formats.
· Les dates contenant des valeurs d'année à deux chiffres sont ambiguës car le siècle n'est pas connu. MySQL interprète les valeurs d'année à deux chiffres en utilisant les règles suivantes :
o Les valeurs d'année comprises entre 70 et 99 sont converties en 1970-1999.
o Les valeurs annuelles comprises entre 00 et 69 sont converties en 2000-2069.
· Bien que MySQL tente d'interpréter les valeurs dans plusieurs formats, les dates sont toujours dans l'ordre année-mois-jour (par exemple, '98-09-04′), plutôt que mois-jour-année comme c'est le cas. couramment utilisé ailleurs. Ou par ordre jour-mois-année (par exemple, '09-04-98', '04-09-98').
· MySQL convertit automatiquement une valeur de type date ou heure en nombre si la valeur est utilisée dans un contexte numérique, et vice versa.
· Lorsque MySQL rencontre une valeur de type date ou heure hors plage ou illégale pour ce type (comme décrit au début de cette section), il convertit la valeur en valeur "zéro" de cette classe. . Une exception est que les valeurs TIME hors plage sont tronquées au point final correspondant de la plage TIME.
Le tableau suivant montre le format des différentes valeurs "zéro". Veuillez noter que l'utilisation de ces valeurs générera des avertissements si le mode SQL NO_ZERO_DATE est activé.
Valeur "zéro" de type colonne
DATETIME '0000-00-00 00:00:00′
DATE '0000-00-00′
TIMESTAMP 00000000000000
TIME '00:00:00′
ANNÉE 0000
· La valeur "zéro" est une valeur spéciale, mais vous pouvez utiliser le affichage dans le tableau Les valeurs sont enregistrées explicitement ou s'y réfèrent. Vous pouvez également utiliser la valeur « 0 » ou 0 pour enregistrer ou référencer, ce qui est plus facile à écrire.
· Les valeurs de date ou d'heure "zéro" utilisées dans MyODBC sont automatiquement converties en NULL dans MyODBC 2.50.12 et supérieur car ODBC ne peut pas gérer de telles valeurs.
11.3.1 Types DATETIME, DATE et TIMESTAMP
11.3.1.1.
Attribut TIMESTAMP depuis MySQL 4.1
Les types DATETIME, DATE et TIMESTAMP sont liés. Cette section décrit leurs caractéristiques, leurs similitudes et leurs différences.
Utilisez le type DATETIME lorsque vous avez besoin d'une valeur contenant à la fois des informations de date et d'heure. MySQL récupère et affiche les valeurs DATETIME au format 'AAAA-MM-JJ HH:MM:SS'. La plage prise en charge va de « 1000-01-01 00:00:00 » à « 9999-12-31 23:59:59 ». ("Supporté" signifie que même si la valeur précédente peut fonctionner, il n'y a aucune garantie).
Le type DATE doit être utilisé lorsque vous n'avez besoin que de la valeur de date sans la partie heure. MySQL utilise le format 'AAAA-MM-JJ' pour récupérer et afficher les valeurs DATE. La plage prise en charge va de « 1000-01-01 » à « 9999-12-31 ».
Les propriétés du type de colonne TIMESTAMP ne sont pas fixes et dépendent de la version de MySQL et du mode SQL dans lequel le serveur s'exécute. Ces propriétés sont décrites plus loin dans cette section.
Les valeurs DATETIME, DATE et TIMESTAMP peuvent être spécifiées en utilisant n'importe quel format courant :
· 'AAAA-MM-JJ HH:MM:SS' ou 'AA-MM-JJ HH : MM:SS 'Formater la chaîne. La syntaxe « détendue » est autorisée : n'importe quel caractère de ponctuation peut être utilisé comme séparateur entre les parties de date ou les parties d'heure. Par exemple, '98-12-31 11:30:45', '98.12.31 11 30 45', '98/12/31 11*30*45' et '98@12@31 11^30^45'. sont équivalents.
· Une chaîne au format 'AAAA-MM-JJ' ou 'AA-MM-JJ'. La syntaxe « détendue » est également autorisée ici. Par exemple, « 98-12-31 », « 98.12.31 », « 98/12/31 » et « 98@12@31 » sont équivalents.
· Une chaîne au format 'AAAAMMJJHHMMSS' ou 'AAMMJJHHMMSS' sans séparateurs, en supposant que la chaîne est significative pour les types de date. Par exemple, « 19970523091528 » et « 970523091528 » sont interprétés comme « 1997-05-23 09:15:28 », mais « 971122129015 » est illégal (il comporte une partie minutes dénuée de sens) et deviendra « 0000- 00-00 00 ». :00:00′.
· Une chaîne au format 'AAAAMMJJ' ou 'AAMMJJ' sans séparateurs, en supposant que la chaîne soit significative pour les types de date. Par exemple, « 19970523 » et « 970523 » sont interprétés comme « 1997-05-23 », mais « 971332 » est illégal (il a une partie mois et jour sans signification) et deviendra « 0000-00-00 ».
· Un nombre au format AAAAMMJJHHMMSS ou AAMMJJHHMMSS, en supposant que le nombre ait un sens pour le type de date. Par exemple, 19830905132800 et 830905132800 sont interprétés comme « 1983-09-05 13:28:00 ».
· Un nombre au format AAAAMMJJ ou AAMMJJ, en supposant que le nombre ait un sens pour le type de date. Par exemple, 19830905 et 830905 sont interprétés comme « 1983-09-05 ».
· Le résultat renvoyé par la fonction, la valeur est adaptée au contexte DATETIME, DATE ou TIMESTAMP, tel que NOW() ou CURRENT_DATE.
Les valeurs DATETIME, DATE ou TIMESTAMP invalides sont converties en une valeur "zéro" du type correspondant ('0000-00-00 00:00:00', '0000-00-00' ou 00000000000000 ).
Pour les valeurs de chaîne qui incluent des séparateurs de parties de date, il n'est pas nécessaire de spécifier deux chiffres si les valeurs du jour et du mois sont inférieures à 10. « 1979-6-9 » est identique à « 1979-06-09 ». De même, pour les valeurs de chaîne qui incluent des séparateurs de parties horaires, si les valeurs des heures, des minutes et des secondes sont inférieures à 10, il n'est pas nécessaire de spécifier deux chiffres. « 1979-10-30 1:2:3 » est identique à « 1979-10-30 01:02:03 ».
La valeur numérique doit comporter 6, 8, 12 ou 14 chiffres. Si un nombre comporte 8 ou 14 chiffres, il est supposé être au format AAAAMMJJ ou AAAAMMJJHHMMSS, les 4 premiers chiffres représentant l'année. Si le numéro comporte 6 ou 12 chiffres, il est supposé être au format AAMMJJ ou AAMMJJHHMMSS, les 2 premiers chiffres représentant l'année. Les autres nombres sont interprétés comme s'ils étaient complétés par des zéros à la longueur la plus proche.
Les valeurs spécifiées comme chaînes non qualificatives sont interprétées en utilisant la longueur donnée. Si la chaîne comporte 8 ou 14 caractères, les 4 premiers chiffres représentent l’année. Sinon, les 2 premiers chiffres représentent l'année. Interprétez chaque composant apparaissant dans la chaîne de gauche à droite pour découvrir les valeurs de l'année, du mois, du jour, de l'heure, des minutes et des secondes. Cela signifie que les chaînes de moins de 6 caractères ne doivent pas être utilisées. Par exemple, si vous spécifiez « 9903 », pensant que cela signifie mars 1999, MySQL insérera une valeur de date « zéro » dans votre table. En effet, les valeurs de l'année et du mois sont 99 et 03, mais la partie jour est complètement manquante, donc la valeur n'est pas une date légale. Toutefois, vous pouvez spécifier explicitement une valeur zéro pour représenter la partie du mois ou du jour manquante. Par exemple, vous pouvez utiliser « 990300 » pour insérer la valeur « 1999-03-00 ».
Dans une certaine mesure, il est possible d'attribuer une valeur d'un type de date à un type de date différent. Cependant, la valeur peut changer ou perdre certaines informations :
· Si vous attribuez une valeur DATE à un objet DATETIME ou TIMESTAMP, la partie heure de la valeur résultante est définie sur « 00:00:00 » en raison de la valeur DATE Aucune information temporelle incluse.
· Si vous attribuez une valeur DATETIME ou TIMESTAMP à un objet DATE, la partie heure de la valeur résultante est supprimée car la valeur DATE ne contient pas d'informations temporelles.
· N'oubliez pas que bien que les valeurs DATETIME, DATE et TIMESTAMP puissent être spécifiées en utilisant le même format, les plages pour les différents types de valeurs sont différentes. Par exemple, la valeur TIMESTAMP ne peut pas être antérieure à 1970 ni postérieure à 2037. Cela indique qu'une date, telle que « 1968-01-01 », bien que valide pour les valeurs DATETIME ou DATE, n'est pas valide pour les valeurs TIMESTAMP et sera convertie en 0 si elle est attribuée à un tel objet.
Soyez conscient de certains pièges lors de la spécification de valeurs de date :
· Le format non strict autorisé pour les valeurs spécifiées sous forme de chaînes peut être trompeur. Par exemple, la valeur « 10:11:12 » peut ressembler à une valeur temporelle en raison du séparateur « : », mais si elle est utilisée dans un contexte de date, la valeur est interprétée comme l'année « 2010-11-12 ». La valeur « 10:45:15 » est convertie en « 0000-00-00 » car « 45 » n'est pas un mois légal.
· En mode non strict, le serveur MySQL effectue uniquement des vérifications de base sur la validité des dates : les plages d'année, de mois et de jour sont respectivement de 1000 à 9999, de 00 à 12 et de 00 à 31. Toutes les dates contenant des parties en dehors de ces plages sont converties en « 0000-00-00 ». Notez que vous êtes toujours autorisé à enregistrer des dates illégales, telles que « 2002-04-31 ». Pour vous assurer que les dates sont valides lorsque vous n'utilisez pas le mode strict, vous devez vérifier votre candidature.
En mode strict, les dates illégales ne sont pas acceptées et ne sont pas converties.
Pour plus de détails, consultez la Section 5.3.2, « Mode SQL Server ».
· Les dates contenant des valeurs d'année à deux chiffres sont ambiguës car le siècle n'est pas connu. MySQL utilise les règles suivantes pour interpréter les valeurs d'année à deux chiffres :
o Les valeurs d'année comprises entre 00 et 69 sont converties en 2000-2069.
o Les valeurs annuelles comprises entre 70 et 99 sont converties en 1970-1999.
11.3.1.1. Attributs de type TIMESTAMP depuis MySQL 4.1
Remarque : Dans les anciennes versions de MySQL (avant 4.1), les attributs de type colonne TIMESTAMP étaient dans de nombreux façons Très différent de ce qui est décrit dans cette section. Si vous devez convertir d'anciennes données TIMESTAMP pour fonctionner dans MySQL 5.1, consultez le manuel de référence MySQL 4.1 pour plus de détails.
Le format d'affichage de la colonne TIMESTAMP est le même que celui de la colonne DATETIME. Autrement dit, la largeur d'affichage est fixée à 19 caractères, et le format est AAAA-MM-JJ HH:MM:SS.
Le serveur MySQL peut également fonctionner en mode MAXDB. Lorsque le serveur fonctionne dans ce mode, TIMESTAMP est égal à DATETIME. Autrement dit, si le serveur s'exécute en mode MAXDB lors de la création de la table, la colonne TIMESTAMP est créée en tant que colonne DATETIME. Le résultat est que la colonne utilise le format d'affichage DATETIME, a la même plage de valeurs et n'est pas automatiquement initialisée ou mise à jour avec la date et l'heure actuelles.
Pour activer le mode MAXDB, utilisez l'option de serveur –sql-mode=MAXDB lors du démarrage du serveur ou définissez le mode du serveur SQL sur MAXDB au moment de l'exécution en définissant la variable globale sql_mode :
Le client peut faire fonctionner le serveur en mode MAXDB pour sa connexion comme suit :
MySQL n'accepte pas les fichiers dans Japon ou la colonne Mois contient un zéro ou une valeur d'horodatage contenant une valeur de date illégale. La seule exception à cette règle est la valeur spéciale « 0000-00-00 00:00:00 ».
Vous pouvez déterminer de manière très flexible quand initialiser et mettre à jour TIMESTAMP et quelles colonnes initialiser et mettre à jour :
· Vous pouvez spécifier l'horodatage actuel comme valeur par défaut et valeur automatiquement mise à jour. Mais vous ne pouvez en choisir qu’un, ou aucun des deux. (Il n'est pas possible qu'une colonne sélectionne un comportement et qu'une autre colonne sélectionne un autre comportement).
· Vous pouvez spécifier quelle colonne TIMESTAMP est automatiquement initialisée ou mise à jour à la date et à l'heure actuelles. La 1ère colonne TIMESTAMP n'est plus nécessaire.
Veuillez noter que les informations décrites ci-dessous s'appliquent uniquement aux colonnes TIMESTAMP dans les tables créées sans le mode MAXDB activé. (Comme mentionné ci-dessus, le mode MAXDB entraîne la création de colonnes en tant que colonnes DATETIME). Les règles qui contrôlent l'initialisation et la mise à jour des colonnes TIMESTAMP sont les suivantes :
· Si la première colonne TIMESTAMP d'une table est spécifiée comme valeur DEFAULT, elle ne peut pas être ignorée. La valeur par défaut peut être CURRENT_TIMESTAMP ou une valeur de date et d'heure constante.
· DEFAULT NULL est le même que DEFAULT CURRENT_TIMESTAMP de la 1ère colonne TIMESTAMP. Pour les autres colonnes TIMESTAMP, DEFAULT NULL est traité comme DEFAULT 0.
· N'importe quelle colonne TIMESTAMP du tableau peut être définie pour s'initialiser automatiquement avec l'horodatage actuel et/ou la mise à jour.
· Dans l'instruction CREATE TABLE, vous pouvez déclarer la première colonne TIMESTAMP de l'une des manières suivantes :
o Utilisez les clauses DEFAULT CURRENT_TIMESTAMP et ON UPDATE CURRENT_TIMESTAMP pour utiliser la valeur par défaut. horodatage actuel et mis à jour automatiquement.
o N'utilise pas la clause DEFAULT ou ON UPDATE, identique à DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP.
o Utilisez la clause DEFAULT CURRENT_TIMESTAMP au lieu de la clause ON UPDATE La colonne utilise l'horodatage actuel comme valeur par défaut mais ne se met pas à jour automatiquement.
o Sans la clause DEFAULT mais avec la clause ON UPDATE CURRENT_TIMESTAMP, la colonne a une valeur par défaut de 0 et est mise à jour automatiquement.
o Utilisez la valeur constante DEFAULT, avec la valeur par défaut donnée répertoriée. Si la colonne comporte une clause ON UPDATE CURRENT_TIMESTAMP, elle se met à jour automatiquement, sinon ce n'est pas le cas.
En d'autres termes, vous pouvez utiliser l'horodatage actuel pour la valeur initiale et la valeur mise à jour automatiquement, ou l'un ou l'autre, ou ni l'un ni l'autre. (Par exemple, vous pouvez spécifier ON UPDATE pour activer les mises à jour automatiques sans que les colonnes soient automatiquement initialisées).
· Vous pouvez utiliser CURRENT_TIMESTAMP, CURRENT_TIMESTAMP() ou NOW() dans les clauses DEFAULT et ON UPDATE. Ils ont tous le même effet.
L'ordre des deux propriétés n'a pas d'importance. Si DEFAULT et ON UPDATE sont spécifiés pour une colonne TIMESTAMP, l’un ou l’autre peut précéder l’autre.
Exemple, les affirmations suivantes sont équivalentes :
· Pour spécifier la valeur par défaut ou la mise à jour automatique pour une colonne TIMESTAMP autre que la colonne 1, vous devez désactiver l'initialisation et la mise à jour automatiques en attribuant explicitement à la 1ère colonne TIMESTAMP une valeur DEFAULT constante. (Par exemple, DEFAULT 0 ou DEFAULT’2003-01-01 00:00:00′). Ensuite, pour les autres colonnes TIMESTAMP, les règles sont les mêmes que pour la première colonne TIMESTAMP, à l'exception du fait que les clauses DEFAULT et ON UPDATE ne peuvent être ignorées. Si vous faites cela, aucune initialisation ou mise à jour ne se produira automatiquement.
Par exemple : les déclarations suivantes sont équivalentes :
Vous pouvez définir le fuseau horaire actuel pour chaque connexion, Voir Section 5.10.8, « Prise en charge du fuseau horaire de MySQL Server » pour les descriptions associées. Les valeurs TIMESTAMP sont enregistrées au format UTC, converties au fuseau horaire actuel lors du stockage et reconverties au fuseau horaire actuel lors de la récupération. Tant que la valeur de réglage du fuseau horaire est constante, la valeur au moment de la sauvegarde peut être obtenue. Si vous enregistrez une valeur TIMESTAMP, vous devez modifier le fuseau horaire puis récupérer la valeur, elle sera différente de la valeur que vous avez enregistrée. En effet, le même fuseau horaire n’est pas utilisé dans la conversion dans les deux sens. Le fuseau horaire actuel peut être utilisé comme valeur de la variable système time_zone.
Vous pouvez inclure l'attribut NULL dans la définition d'une colonne TIMESTAMP pour permettre à la colonne de contenir des valeurs NULL. Par exemple :
Si l'attribut NULL n'est pas spécifié, définir la colonne sur NULL la définira sur l'horodatage actuel. Veuillez noter qu'une colonne TIMESTAMP qui autorise les valeurs NULL n'acceptera pas l'horodatage actuel à moins que sa valeur par défaut ne soit définie comme CURRENT_TIMESTAMP, ou que NOW() ou CURRENT_TIMESTAMP soit inséré dans la colonne. En d'autres termes, une colonne TIMESTAMP définie comme NULL ne sera automatiquement mise à jour que si elle est créée avec :
Sinon, c'est-à-dire si NULL est utilisé à la place DEFAULT TIMESTAMP pour définir la colonne TIMESTAMP comme suit...
... alors vous devez explicitement insérer une valeur correspondant à la date et l'heure actuelles. Par exemple :
11.3.2 Type TIME
MySQL récupère et affiche les valeurs TIME dans 'HH:MM : Format SS' (ou format 'HHH:MM:SS' pour les grandes valeurs horaires). Les valeurs TIME peuvent aller de « -838:59:59 » à « 838:59:59 ». La raison pour laquelle la partie heure est si grande est que le type TIME peut être utilisé non seulement pour représenter l'heure de la journée (qui doit être inférieure à 24 heures), mais également le temps écoulé depuis un événement ou l'intervalle de temps entre deux heures. événements (qui peuvent être supérieurs à 24 heures, voire négatifs).
Vous pouvez spécifier la valeur TIME dans différents formats :
· Une chaîne au format 'D HH:MM:SS.fraction'. Vous pouvez également utiliser l'une des syntaxes « non strictes » suivantes : 'HH:MM:SS.fraction', 'HH:MM:SS', 'HH:MM', 'D HH:MM:SS', 'D HH : MM', 'D HH' ou 'SS'. Ici D représente le jour, qui peut prendre une valeur comprise entre 0 et 34. Veuillez noter que MySQL ne sauvegarde pas encore les scores.
· Une chaîne au format 'HHMMSS' sans séparateurs, en supposant une heure significative. Par exemple, « 101112 » signifie « 10:11:12 », mais « 109712 » est illégal (il comporte une partie minutes dénuée de sens) et deviendra « 00:00:00 ».
· Valeur au format HHMMSS, supposée être une heure significative. Par exemple, 101112 signifie « 10:11:12 ». Les formats suivants sont également compris : SS, MMSS, HHMMSS, HHMMSS.fraction. Veuillez noter que MySQL ne sauvegarde pas encore les scores.
· Le résultat renvoyé par la fonction avec une valeur appropriée au contexte TIME, telle que CURRENT_TIME.
Pour les valeurs TIME spécifiées sous forme de chaînes comprenant des séparateurs de parties horaires, il n'est pas nécessaire de spécifier deux chiffres si la valeur de l'heure, des minutes ou des secondes est inférieure à 10. « 8:3:2 » est identique à « 08:03:02 ».
Des précautions doivent être prises lors de l'attribution de valeurs abrégées à la colonne TIME. Sans les deux points, MySQL interprète la valeur en supposant que les deux chiffres les plus à droite représentent les secondes. (MySQL interprète la valeur TIME comme l'heure passée plutôt que l'heure de la journée). Par exemple, vous pourriez penser que « 1112 » et 1112 signifient « 11:12:00 » (11 heures 12 minutes), mais MySQL les interprète comme « 00:11:12 » (11 minutes, 12 secondes). De même, « 12 » et 12 sont interprétés comme « 00:00:12 ». En revanche, les deux points dans une valeur TIME sont toujours traités comme l'heure de la journée. Autrement dit, « 11:12 » signifie « 11:12:00 », et non « 00:11:12 ».
Les valeurs qui sont en dehors de la plage TIME mais qui sont légales sont tronquées au point final le plus proche de la plage. Par exemple, « -850:00:00 » et « 850:00:00 » sont convertis en « -838:59:59 » et « 838:59:59 ».
Les valeurs TIME invalides sont converties en « 00:00:00 ». Veuillez noter que puisque « 00:00:00 » est lui-même une valeur TIME légale, seule une valeur « 00:00:00 » enregistrée dans le tableau ne peut pas dire si la valeur d'origine est « 00:00:00 » ou une valeur illégale. .
11.3.3 Type d'ANNÉE
Le type YEAR est un type à un octet utilisé pour représenter l'année.
MySQL récupère et affiche les valeurs de l'ANNÉE au format AAAA. La plage va de 1901 à 2155.
Vous pouvez spécifier les valeurs de l'ANNÉE dans différents formats :
· Chaîne à quatre chiffres, allant de « 1901 » à « 2155 ».
· Quatre chiffres, allant de 1901 à 2155.
· Chaîne à deux chiffres, allant de « 00 » à « 99 ». Les valeurs comprises entre '00' et '69' et '70' à '99' sont converties en valeurs ANNÉE comprises entre 2000 et 2069 et entre 1970 et 1999.
· Entier à deux chiffres compris entre 1 et 99. Les valeurs comprises entre 1 et 69 et entre 70 et 99 sont converties en valeurs ANNÉE comprises entre 2001 et 2069 et entre 1970 et 1999. Notez que les plages d'entiers à deux chiffres sont légèrement différentes des plages de chaînes à deux chiffres dans la mesure où vous ne pouvez pas spécifier directement zéro sous forme de nombre et le faire interpréter comme 2000. Vous devez le spécifier sous la forme d'une chaîne « 0 » ou « 00 », sinon il sera interprété comme 0000.
· Le résultat renvoyé par la fonction, dont la valeur est appropriée pour le contexte YEAR, comme NOW().
Les valeurs ANNÉE illégales sont converties en 0000.
11.3.4. Questions relatives à l'an 2000 et types de dates
MySQL est intrinsèquement sûr pour l'an 2000 (Y2K) (voir Section 1.4.5, « Compatibilité avec l'an 2000 » ») , mais la valeur saisie dans MySQL peut ne pas être sûre. Toute entrée contenant une valeur d'année à deux chiffres sera ambiguë car le siècle n'est pas connu. Ces valeurs doivent être interprétées comme quatre chiffres car MySQL utilise quatre chiffres en interne pour stocker l'année.
Pour les types DATETIME, DATE, TIMESTAMP et YEAR, MySQL utilise les règles suivantes pour interpréter les dates avec des valeurs d'année ambiguës :
· Les valeurs d'année comprises entre 00 et 69 sont converties à 2000-2069.
· Les valeurs annuelles comprises entre 70 et 99 sont converties en 1970-1999.
N'oubliez pas que ces règles ne sont que des suppositions raisonnables sur ce que représentent les valeurs des données. Si l'heuristique utilisée par MySQL ne produit pas la valeur correcte, vous devez fournir l'entrée exacte contenant la valeur de l'année à quatre chiffres.
ORDER BY peut trier correctement les valeurs TIMESTAMP ou YEAR avec deux chiffres de l'année.
Certaines fonctions telles que MIN() et MAX() convertissent TIMESTAMP ou YEAR en nombre. Cela signifie que ces fonctions ne fonctionnent pas correctement avec des valeurs comportant des valeurs annuelles à deux chiffres. Le correctif dans ce cas consiste à convertir TIMESTAMP ou YEAR au format année à quatre chiffres ou à utiliser MIN(DATE_ADD(TIMESTAMP,INTERVAL 0 DAYS)).
11.4. Types de chaîne
11.4.1 Types CHAR et VARCHAR 11.4.2.
Types BINARY et VARBINARY 11.4.3. 🎜>11.4.4. Type ENUM 11.4.5. Type SET
Les types de chaîne font référence à CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM et SET. Cette section décrit le fonctionnement de ces types et comment les utiliser dans les requêtes.
11.4.1. Types CHAR et VARCHAR
La longueur déclarée pour les types CHAR et VARCHAR indique le nombre maximum de caractères que vous souhaitez enregistrer. Par exemple, CHAR(30) peut occuper 30 caractères.
La longueur de la colonne CHAR est fixée à la longueur déclarée lors de la création du tableau. La longueur peut être n'importe quelle valeur comprise entre 0 et 255. Lors de l'enregistrement des valeurs CHAR, remplissez-les vers la droite avec des espaces jusqu'à la longueur spécifiée. Lorsqu'une valeur CHAR est récupérée, les espaces de fin sont supprimés. Aucune conversion de cas n'est effectuée pendant le stockage ou la récupération.
Les valeurs de la colonne VARCHAR sont des chaînes de longueur variable. La longueur peut être spécifiée comme une valeur comprise entre 0 et 65 535. (La longueur effective maximale de VARCHAR est déterminée par la taille maximale des lignes et le jeu de caractères utilisé. La longueur maximale globale est de 65 532 octets).
Par rapport à CHAR, lorsque la valeur VARCHAR est enregistrée, seul le nombre requis de caractères est enregistré, plus un octet pour enregistrer la longueur (si la longueur déclarée de la colonne dépasse 255, deux octets sont utilisés).
Les valeurs VARCHAR sont enregistrées sans remplissage. Les espaces de fin sont conservés lorsque la valeur est enregistrée et récupérée, conformément au SQL standard.
Si la valeur attribuée à une colonne CHAR ou VARCHAR dépasse la longueur maximale de la colonne, la valeur est coupée pour s'adapter. Si le caractère tronqué n'est pas un espace, un avertissement est généré. Si des caractères autres que des espaces sont tronqués, cela provoque une erreur (au lieu d'un avertissement) et désactive l'insertion de valeurs en utilisant le mode SQL strict. Voir Section 5.3.2, « Mode SQL Server ».
Le tableau suivant montre les résultats de l'enregistrement de diverses valeurs de chaîne dans les colonnes CHAR(4) et VARCHAR(4), illustrant la différence entre CHAR et VARCHAR :
Les valeurs récupérées des colonnes CHAR(4) et VARCHAR(4) ne sont pas toujours les mêmes car les espaces de fin sont supprimés de la colonne CHAR lors de la récupération. L'exemple suivant illustre la différence :
Trie et compare les valeurs dans les colonnes CHAR et VARCHAR selon les règles de classement du jeu de caractères attribuées à la colonne.
Veuillez noter que toutes les règles de classement MySQL appartiennent à la classe PADSPACE. Cela signifie que toutes les valeurs CHAR et VARCHAR dans MySQL n'ont pas besoin de prendre en compte les espaces de fin lors de leur comparaison. Par exemple :
Veuillez noter que cela est vrai pour toutes les versions de MySQL et que cela n'est pas affecté par le mode serveur SQL.
Dans les cas où les caractères de remplissage de fin sont tronqués ou ignorés lors de la comparaison, si l'index de colonne nécessite une valeur unique, l'insertion d'une valeur dans la colonne qui ne diffère que par le nombre de caractères de remplissage entraînera une valeur de clé en double. erreur.
CHAR BYTE est un alias pour CHAR BINARY. Ceci afin de garantir la compatibilité.
L'attribut ASCII attribue le jeu de caractères latin1 à la colonne CHAR. L'attribut UNICODE attribue le jeu de caractères ucs2.
11.4.2. Types BINARY et VARBINARY
Les classes BINARY et VARBINARY sont similaires à CHAR et VARCHAR, sauf qu'elles contiennent des chaînes binaires au lieu de chaînes non binaires. . Autrement dit, ils contiennent des chaînes d'octets plutôt que des chaînes de caractères. Cela signifie qu'ils n'ont pas de jeu de caractères et que le tri et la comparaison sont basés sur la valeur numérique des octets de valeur de colonne.
Les longueurs maximales autorisées de BINARY et VARBINARY sont les mêmes, tout comme CHAR et VARCHAR. La différence est que la longueur de BINARY et VARBINARY est la longueur des octets plutôt que la longueur des caractères.
Les types de données BINARY et VARBINARY sont différents des types de données CHAR BINARY et VARCHAR BINARY. Pour ce dernier type, la propriété BINARY ne traite pas la colonne comme une colonne de chaîne binaire. Au lieu de cela, les règles de classement binaire du jeu de caractères de la colonne sont utilisées et la colonne elle-même contient des chaînes de caractères non binaires plutôt que des chaînes d'octets binaires. Par exemple, CHAR(5) BINARY est traité comme CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin, en supposant que le jeu de caractères par défaut est latin1. Ceci est différent de BINARY(5), qui contient une chaîne binaire de 5 octets sans jeu de caractères ni règles de classement.
Lors de l'enregistrement des valeurs BINAIRES, remplissez-les vers la droite avec des valeurs de la longueur spécifiée. La valeur de remplissage est 0×00 (zéro octet). Ajoute 0 × 00 à droite lors de l'insertion d'une valeur et ne supprime pas les octets de fin lors de la sélection. Tous les octets sont importants lors de la comparaison, y compris les opérations ORDER BY et DISTINCT. Lors de la comparaison, 0×00 octets et espaces sont différents, 0×00
Par exemple : pour une colonne BINARY(3), 'a' devient 'a' une fois inséré. « a » devient « a » une fois inséré. Aucune des valeurs insérées ne change lorsqu’elle est sélectionnée.
Pour VARBINARY, les caractères ne sont pas complétés lorsqu'ils sont insérés et les octets ne sont pas tronqués lorsqu'ils sont sélectionnés. Tous les octets sont importants lors de la comparaison, y compris les opérations ORDER BY et DISTINCT. Lors de la comparaison, 0×00 octets et espaces sont différents, 0×00
Dans les cas où les caractères de remplissage de fin sont tronqués ou ignorés lors de la comparaison, si l'index de colonne nécessite une valeur unique, l'insertion d'une valeur dans la colonne qui ne diffère que par le nombre de caractères de remplissage entraînera une valeur de clé en double. erreur.
Si vous envisagez d'utiliser ces types de données pour enregistrer des données binaires et que vous devez récupérer exactement la même valeur que la valeur enregistrée, vous devez considérer les fonctionnalités de remplissage et de découpage décrites précédemment. L'exemple suivant illustre comment une valeur BINAIRE complétée par 0 × 00 affecte la comparaison des valeurs de colonne :
if The La valeur récupérée doit être la même que la valeur spécifiée pour le stockage sans remplissage, de préférence en utilisant le type de données BLOB.
MySQL peut modifier silencieusement le type d'une colonne BINARY ou VARBINARY lors de la création d'une table. Voir la Section 13.1.5.1, « Modifications des spécifications de la colonne silencieuse ».
11.4.3 Types BLOB et TEXTE
BLOB est un gros objet binaire qui peut contenir une quantité variable de données. Il existe 4 types de BLOB : TINYBLOB, BLOB, MEDIUMBLOB et LONGBLOB. Ils ne diffèrent que par la longueur maximale pendant laquelle ils peuvent contenir une valeur.
Il existe 4 types de TEXTE : TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT. Ceux-ci correspondent à 4 types de BLOB, avec la même longueur maximale et les mêmes exigences de stockage.
Voir la section 11.5, « Exigences de stockage par type de colonne ».
Les colonnes BLOB sont traitées comme des chaînes binaires (chaînes d'octets). Les colonnes TEXT sont traitées comme des chaînes non binaires (chaînes de caractères). Les colonnes BLOB n'ont pas de jeu de caractères et le tri et la comparaison sont basés sur la valeur numérique des octets de valeur de colonne. Les colonnes TEXTE ont un jeu de caractères et les valeurs sont triées et comparées selon les règles de classement du jeu de caractères.
Il n'y a pas de conversion de casse lors du stockage ou de la récupération des colonnes TEXT ou BLOB.
Lorsque vous n'exécutez pas en mode strict, si vous attribuez une valeur à une colonne BLOB ou TEXT qui dépasse la longueur maximale du type de colonne, la valeur est tronquée pour s'adapter. Si le caractère tronqué n'est pas un espace, un avertissement sera généré. En utilisant le mode SQL strict, une erreur sera générée et la valeur sera rejetée au lieu d'être interceptée avec un avertissement. Voir Section 5.3.2, « Mode SQL Server ».
À bien des égards, une colonne BLOB peut être considérée comme une colonne VARBINARY qui peut être suffisamment grande. De même, les colonnes TEXT peuvent être traitées comme des colonnes VARCHAR. BLOB et TEXT diffèrent de VARBINARY et VARCHAR des manières suivantes :
· Les espaces de fin ne sont pas supprimés lors de l'enregistrement ou de la récupération des valeurs des colonnes BLOB et TEXT. (C'est la même chose que les colonnes VARBINARY et VARCHAR).
Veuillez noter que le TEXTE sera développé avec des espaces pour s'adapter à l'objet comparé, tout comme CHAR et VARCHAR.
· Pour les index sur les colonnes BLOB et TEXT, la longueur du préfixe de l'index doit être précisée. Pour CHAR et VARCHAR, la longueur du préfixe est facultative. Voir Section 7.4.3, « Index de colonnes ».
· Les colonnes BLOB et TEXT ne peuvent pas avoir de valeurs par défaut.
LONG et LONG VARCHAR correspondent au type de données MEDIUMTEXT. Ceci afin de garantir la compatibilité. Si le type de colonne TEXT utilise l'attribut BINARY, la colonne se verra attribuer le classement binaire du jeu de caractères de la colonne.
MySQL Connector/ODBC définit les valeurs BLOB comme LONGVARBINARY et les valeurs TEXT comme LONGVARCHAR.
Les valeurs BLOB et TEXT pouvant être très longues, vous pouvez rencontrer certaines contraintes lors de leur utilisation :
· Seuls les premiers octets max_sort_length de la colonne sont utilisés lors du tri. La valeur par défaut de max_sort_length est 1024 ; cette valeur peut être modifiée en utilisant l'option –max_sort_length lors du démarrage du serveur mysqld. Voir Section 5.3.3, « Variables système du serveur ».
Augmenter la valeur de max_sort_length au moment de l'exécution peut rendre plus d'octets significatifs lors du tri ou de la combinaison. N'importe quel client peut modifier la valeur de sa variable de session max_sort_length :
Lorsque vous souhaitez donner un sens aux octets plus longs que max_sort_length, c'est vrai. Une autre façon utiliser GROUP BY ou ORDER BY pour les colonnes BLOB ou TEXT contenant des valeurs longues revient à convertir les valeurs de colonne en objets de longueur fixe. L'approche standard consiste à utiliser la fonction SUBSTRING. Par exemple, l'instruction suivante trie 2 000 octets de la colonne de commentaires : La valeur maximale réelle pouvant être transmise entre le client et le serveur est déterminée par la quantité de mémoire disponible et la taille du tampon de communication. Vous pouvez modifier la taille du tampon de messages en modifiant la valeur de la variable max_allowed_packet, mais vous devez modifier à la fois les programmes serveur et client. Par exemple, vous pouvez utiliser mysql et mysqldump pour modifier la valeur max_allowed_packet du client. Voir Section 7.5.2, « Ajustement des paramètres du serveur », Section 8.3, « mysql : outil de ligne de commande MySQL » et Section 8.8, « mysqldump : programme de sauvegarde de base de données ».
Chaque valeur BLOB ou TEXT est représentée respectivement par un objet alloué en interne. Cela contraste avec les autres types de colonnes, qui allouent un moteur de stockage à chaque colonne lorsque la table est ouverte.
11.4.4. Type ENUM
ENUM est un objet chaîne dont les valeurs proviennent d'une colonne de valeurs qui sont explicitement énumérées dans la spécification de la colonne lorsque le tableau est créé.
· Si vous insérez une valeur illégale dans ENUM (c'est-à-dire la colonne des valeurs autorisées chaîne), une chaîne vide est insérée comme valeur d'erreur spéciale. Cette chaîne est différente de la chaîne vide "normale", qui est discutée en détail plus tard. Si une colonne ENUM est déclarée pour autoriser NULL, la valeur NULL est une valeur valide. pour la colonne, et la valeur par défaut est NULL. Si la colonne ENUM est déclarée NON NULL, sa valeur par défaut est le premier élément de la colonne de valeurs autorisées 🎜>
· Les valeurs de la colonne sont numérotées à partir de 1 à partir des valeurs autorisées spécifiées dans la colonne
· Valeur d'erreur de chaîne vide La valeur d'index est 0. Cela signifie que vous pouvez utiliser le SELECT suivant. instruction pour rechercher les lignes avec des valeurs ENUM illégales attribuées :
· L'index des valeurs NULL est NULL . une colonne définie comme ENUM (« un », « deux », « trois ») peut avoir n'importe quelle valeur indiquée ci-dessous. L'index de chaque valeur est également affiché :
Indice de valeur
NULL NULL
🎜>
'Un
' Deux '2
' Trois' 3
Une énumération peut contenir jusqu'à 65 535 éléments.
Lors de la création d'un tableau, les espaces de fin dans les valeurs des membres ENUM seront automatiquement supprimés.
Lors de la récupération, les valeurs stockées dans la colonne ENUM sont affichées en utilisant la casse utilisée dans la définition de la colonne. Veuillez noter que les colonnes ENUM peuvent se voir attribuer des jeux de caractères et des règles de classement. Pour les règles de classement binaires ou sensibles à la casse, la casse doit être prise en compte lors de l'attribution de valeurs aux colonnes.
Si une valeur ENUM est récupérée dans un contexte numérique, l'index de la valeur de la colonne sera renvoyé. Par exemple, vous pouvez rechercher des valeurs numériques dans une colonne ENUM comme ceci :
Si vous enregistrez un numéro dans une colonne ENUM, le numéro est traité en tant qu'index, et la valeur enregistrée est le membre d'énumération correspondant à cet index. (Cependant, cela ne fonctionne pas avec LOAD DATA, qui traite toutes les entrées comme des chaînes). Il n'est pas recommandé de définir une colonne ENUM à l'aide de valeurs d'énumération de type numérique, car cela peut facilement prêter à confusion. Par exemple, la colonne suivante contient des membres d'énumération avec les valeurs de chaîne « 0 », « 1 » et « 2 », mais les valeurs d'index numérique 1, 2 et 3 :
Trier les valeurs ENUM selon l'ordre dans lequel les membres de l'énumération sont répertoriés dans la définition de la colonne. (En d'autres termes, les valeurs ENUM sont triées selon le numéro d'index). Par exemple, pour ENUM('a', 'b'), 'a' vient avant 'b', mais pour ENUM('b', 'a'), 'b' vient avant 'a'. Les chaînes vides sont triées avant les chaînes non vides et les valeurs NULL sont triées avant toutes les autres valeurs d'énumération. Pour éviter des résultats inattendus, spécifiez les colonnes ENUM par ordre alphabétique. Vous pouvez également utiliser GROUP BY CAST(col AS CHAR) ou GROUP BY CONCAT(col) pour garantir que les colonnes sont triées lexicalement plutôt que numériquement.
Si vous souhaitez déterminer toutes les valeurs possibles pour une colonne ENUM, utilisez SHOW COLUMNS FROM tbl_name LIKE enum_col et analysez la définition ENUM pour la colonne 2 dans la sortie.
11.4.5. Type SET
SET est un objet chaîne qui peut avoir zéro ou plusieurs valeurs, et sa valeur provient de l'une des colonnes autorisées spécifiées lorsque le la table a été créée en valeur. Lorsque vous spécifiez une valeur de colonne SET qui inclut plusieurs membres SET, utilisez des virgules (« , ») pour séparer chaque membre. De cette façon, la valeur du membre SET elle-même ne peut pas contenir de virgules.
Par exemple, une colonne spécifiée comme SET('one', 'two') NOT NULL peut avoir l'une des valeurs suivantes :
SET Il peut y avoir jusqu'à 64 membres différents.
Lors de la création d'un tableau, les espaces de fin dans les valeurs des membres SET seront automatiquement supprimés.
Lors de la récupération, la valeur stockée dans la colonne SET est affichée en utilisant la casse utilisée dans la définition de la colonne. Veuillez noter que les colonnes SET peuvent se voir attribuer des jeux de caractères et des règles de classement. Pour les règles de classement binaires ou sensibles à la casse, la casse doit être prise en compte lors de l'attribution de valeurs aux colonnes.
MySQL enregistre la valeur SET sous forme de nombre, et le bit de poids faible de la valeur enregistrée correspond au premier membre SET. Si une valeur SET est récupérée dans un contexte numérique, les paramètres de bits de la valeur récupérée correspondent aux membres SET qui composent la valeur de colonne. Par exemple, vous pouvez récupérer une valeur numérique d'une colonne SET comme ceci :
Si vous enregistrez un nombre dans une colonne SET, le nombre de bits dans la la représentation binaire du nombre est déterminée membre SET dans la valeur de la colonne. Pour les colonnes spécifiées comme SET('a','b','c','d'), les membres ont les valeurs décimales et binaires suivantes :
Membre SET Valeur décimale Valeur binaire
'a' 1 0001
'b' 2 0010
'c' 4 0100
Si vous La colonne reçoit une valeur de 9, qui en binaire La forme est 1001, donc les 1er et 4ème membres de valeur SET « a » et « d » sont sélectionnés et les valeurs résultantes sont « a,d ».
Pour les valeurs contenant plusieurs éléments SET, l'ordre dans lequel les éléments sont répertoriés n'a pas d'importance lors de l'insertion de la valeur. Le nombre de fois qu'un élément donné est répertorié dans la valeur n'a pas d'importance. Lorsque la valeur est récupérée ultérieurement, chaque élément de la valeur apparaît une fois, répertoriant les éléments dans l'ordre spécifié lors de la création de la table. Par exemple, en supposant qu'une colonne est spécifiée comme SET('a','b','c','d') :
Insérez la valeur ' a, d', 'd,a', 'a,d,d', 'a,d,a' et 'd,a,d' :
Toutes ces valeurs apparaissent sous la forme « a,d » lors de la récupération :
Si une colonne SET est définie sur une valeur non prise en charge, la valeur est ignoré et avertit :
Les valeurs SET sont triées par ordre numérique. Les valeurs NULL sont triées avant les valeurs SET non NULL.
Habituellement, vous pouvez utiliser la fonction FIND_IN_SET() ou l'opérateur LIKE pour rechercher des valeurs SET :
La première instruction découvre que SET_col contient la ligne de membre de l'ensemble de valeurs. Le second est similaire, mais différent : il trouve les lignes où set_col contient une valeur ailleurs, même dans une sous-chaîne d'un autre membre SET.
Les déclarations suivantes sont également légales :
La première déclaration recherche la valeur qui contient le premier membre de l'ensemble. La deuxième instruction recherche une valeur correspondante exacte. Il convient de prêter attention aux comparaisons de catégorie 2. Le résultat renvoyé en comparant la valeur définie avec « val1, val2 » est différent du résultat renvoyé en comparant la valeur définie avec « val2, val1 ». Les valeurs doivent être spécifiées dans le même ordre que celui indiqué dans la définition de la colonne.
Si vous souhaitez déterminer toutes les valeurs possibles pour une colonne SET, utilisez SHOW COLUMNS FROM tbl_name LIKE set_col et analysez la définition SET pour la colonne 2 dans la sortie.
11.5. Exigences de stockage des types de colonnes
Répertorie les exigences de stockage pour chaque type de colonne pris en charge par MySQL selon la catégorie.
La taille maximale d'une ligne dans une table MyISAM est de 65 534 octets. Chaque colonne BLOB et TEXT n'en représente que 5 à 9 octets.
Si la table MyISAM inclut des types de colonnes de longueur variable, le format d'enregistrement est également de longueur variable. Lors de la création d'une table, MySQL peut changer une colonne d'un type de longueur variable à un type de longueur fixe ou vice versa, sous certaines conditions. Voir la Section 13.1.5.1, « Modifications des spécifications de la colonne silencieuse » pour plus de détails.
Exigences de stockage de type numérique
Exigences de stockage de type de colonne
TINYINT 1 octet
SMALLINT 2 octets
MEDIUMINT 3 octets
INT, INTEGER 4 octets
BIGINT 8 octets
FLOAT(p) si 0 <= p <= 24 est 4 octets, si 25 <= p <= 53 fait 8 octets
FLOAT 4 octets
DOUBLE [PRECISION], élément REAL 8 octets
DECIMAL(M,D), NUMERIC(M,D) Longueur variable ; voir la discussion ci-dessous
BIT(M) À propos de (M 7)/8 octets
Les exigences de stockage de DECIMAL (et NUMERIC) sont spécifiques à la version :
Utilise le format binaire pour compresser 9 nombres décimaux (basés sur 10) en 4 octets pour représenter les valeurs de colonne DECIMAL. Le stockage des parties entières et fractionnaires de chaque valeur est déterminé séparément. Chaque multiple de 9 chiffres nécessite 4 octets, et les bits « restants » nécessitent une partie des 4 octets. Le tableau suivant donne les exigences de stockage pour les bits excédentaires :
Octets restants
Nombre de bits
0 0
1 1
2 1
3 2
4 2 4
8 4
9 4
Exigences de stockage pour la date et l'heure types
Type de colonne Exigences de stockage DATE 3 mots Section
DATETIME 8 octets
TIMESTAMP 4 octets
TIME 3 octets
ANNÉE 1 octet
Exigences de stockage pour le type de chaîne
Type de colonne Exigences de stockage CHAR(M) M octets, 0 < = M <= 255
VARCHAR(M) L 1 octet, où L <= M et 0 <= M <= 65535 (voir note ci-dessous)
BINARY(M ) M octets, 0 < = M <= 255
VARBINARY(M) L 1 octet, où L <= M et 0 <= M <= 255
TINYBLOB , TINYTEXT L 1 octets, où L < 28
BLOB, TEXT L 2 octets, où L < 216
MEDIUMBLOB, MEDIUMTEXT L 3 octets, où L <
LONGBLOB, LONGTEXT L 4 octets, où L ENUM('value1','value2',…) 1 ou 2 octets, selon le nombre de valeurs d'énumération Nombre (jusqu'à 65 535 valeurs ) SET('value1','value2',…) 1, 2, 3, 4 ou 8 octets, selon le nombre de membres de l'ensemble (jusqu'à 64 membres)Les classes VARCHAR, BLOB et TEXT sont des types de longueur variable. Les exigences de stockage de chaque type dépendent de la longueur réelle de la valeur de la colonne (notée L dans le tableau précédent), et non de la taille maximale possible du type. Par exemple, une colonne VARCHAR(10) peut contenir une chaîne d'une longueur maximale de 10. L'exigence de stockage réelle est la longueur de la chaîne (L), plus un octet enregistrant la longueur de la chaîne. Pour la chaîne 'abcd', L vaut 4 et le stockage nécessite 5 octets.
Pour les types CHAR, VARCHAR et TEXT, les valeurs L et M du tableau précédent doivent être interprétées comme des nombres de caractères, et la longueur de ces types dans la définition de colonne représente le nombre de caractères. Par exemple, pour enregistrer une valeur TINYTEXT, il faut L caractères
1 octet.
Pour calculer le nombre d'octets utilisés pour stocker la valeur d'une colonne CHAR, VARCHAR ou TEXT spécifique, vous devez prendre en compte le jeu de caractères utilisé par la colonne. Dans le cas spécifique, lorsque vous travaillez avec Unicode, vous devez vous rappeler que tous les caractères Unicode utilisent le même nombre d'octets. Pour une répartition du stockage utilisé pour les différentes classes de caractères Unicode, voir Section 10.5, « Prise en charge d'Unicode ».
Remarque : La longueur maximale effective d'une colonne VARCHAR est de 65 532 caractères.
Le moteur NDBCLUSTER ne prend en charge que les colonnes à largeur fixe. Cela signifie que les colonnes VARCHAR des tables du cluster MySQL se comportent comme le type CHAR (sauf que chaque enregistrement dispose toujours d'un octet d'espace supplémentaire). Par exemple, dans une table Cluster, chaque enregistrement d'une colonne déclarée comme VARCHAR(100) occupera 101 octets une fois stocké, quelle que soit la longueur de la chaîne dans l'enregistrement réellement stocké.
Les classes BLOB et TEXT nécessitent 1, 2, 3 ou 4 octets pour enregistrer la longueur de la valeur de la colonne, en fonction de la longueur maximale possible de la classe. Voir Section 11.4.3, « Types BLOB et TEXT
».
Dans le moteur de stockage du cluster NDB, l'implémentation des colonnes TEXT et BLOB est différente, où chaque enregistrement de la colonne TEXT se compose de deux parties distinctes. L'un est de taille fixe (256 octets) et est en fait enregistré dans la table d'origine. L'autre inclut toutes les données au-delà de 256 octets, conservées dans une table implicite. Les enregistrements de la deuxième table font toujours 2 000 octets. Cela signifie que si size<= 256, la taille de la colonne TEXTE est de 256 (où size représente la taille de l'enregistrement) ; sinon, la taille est de 256
size (2000–(size–256) 00).
La taille d'un objet ENUM est déterminée par le nombre de valeurs d'énumération différentes. L'énumération utilise un octet et peut avoir 255 valeurs possibles. Lorsque la valeur d'énumération est comprise entre 256 et 65 535, deux octets sont utilisés. Voir Section 11.4.4, « Types ENUM ».
La taille de l'objet SET est déterminée par le nombre de membres différents de l'ensemble. Si la taille définie est N, l'objet occupe (N 7)/8 octets, arrondis à 1, 2, 3, 4 ou 8 octets. Un SET peut compter jusqu'à 64 membres. Voir Section 11.4.5, « Types de SET ».
11.6. Choisir le bon type de colonne
Pour optimiser le stockage, le type le plus précis doit dans tous les cas être utilisé. Par exemple, si les valeurs des colonnes vont de 1 à 99999, MEDIUMINT
UNSIGNED est un bon type si vous utilisez des entiers. Ce type utilise le moins de stockage de tous les types pouvant représenter la valeur de la colonne.
Effectue tous les calculs de base ( , -, *, /) sur les colonnes DECIMAL avec une précision de 65 chiffres décimaux (basés sur 10). Voir Section 11.1.1, « Présentation des types numériques ».
Utilisez des opérations de double précision pour calculer les valeurs DÉCIMALES. Si la précision n'est pas trop importante ou si la vitesse est la priorité la plus élevée, le type DOUBLE est suffisant. Pour obtenir une haute précision, une conversion en types à virgule fixe stockés dans BIGINT peut être effectuée. Cela permet d'effectuer tous les calculs avec des entiers de 64 bits, en reconvertissant les résultats en valeurs à virgule flottante si nécessaire.
11.7. Utilisation de types de colonnes provenant d'autres moteurs de base de données
Afin d'utiliser le code d'exécution SQL écrit par d'autres fournisseurs, MySQL mappe les types de colonnes comme indiqué dans le tableau suivant. Les définitions de table peuvent être facilement importées dans MySQL à partir d'autres moteurs de base de données via ces mappages :
Autres types de vendeurs Types MySQL
BOOL, TINYINT
BOOLEAN TINYINT
CHAR VARYING(M) VARCHAR(M)
DEC DECIMAL
FIXED DECIMAL
FLOAT4 FLOAT
FLOAT8 DOUBLE
INT1 TINYINT
INT2 SMALLINT
INT3 MEDIUMINT
INT4 INT
INT8 BIGINT
LONG VARBINARY MEDIUMBLOB
LONG VARCHAR MEDIUMTEXT
LONG MEDIUMTEXT
MIDDLEINT MEDIUMINT
NUMERIC DECIMAL
lors de la création du type de colonne de table est mappé, puis le type d'origine La définition est ignorée . Si vous créez une table en utilisant le type d'un autre fournisseur, puis exécutez l'instruction DESCRIBE tbl_name, MySQL utilise le type MySQL équivalent pour signaler la structure de la table.
Ce qui précède est le contenu de la série d'apprentissage MySQL 3 : Types de données. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !