Tabla de contenidos
MySQL soporta un número de tipos de columnas divididos en varias categorías: tipos númericos, tipos de fecha y hora, y tipos de cadenas de caracteres. Este capítulo primero hace un repaso de estos tipos de columnas, y luego proporciona una descripción detallada de las propiedades de los tipos de cada categoría, y un resumen de sus requerimientos de almacenamiento. El repaso es intencionalmente breve. Las descripciones más detalladas deben consultarse para obtener más información acerca de los tipos de datos particulares, como los formatos permitidos para especificar los tipos.
MySQL 5.0 soporta extensiones para tratar datos espaciales. Información al respecto se proporciona en Capítulo 18, Extensiones espaciales de MySQL.
Varias descripciones de los tipos de columnas usan estas convenciones:
M
Indica la máxima anchura al mostrar los datos. El máximo ancho de muestra es 255.
D
Se aplica a tipos de coma flotante y de coma fija e indica el
número de dígitos a continuación del punto decimal. El valor
máximo posible es 30, pero no debe ser mayor que
M-2.
Los corchetes ('[' y ']')
indican partes de especificadores de tipos que son opcionales.
A continuación hay un resumen de los tipos de columnas numéricos. Para información adicional, consulte Sección 11.2, “Tipos numéricos”. Los requerimientos de almacenamiento de columna se dan en Sección 11.5, “Requisitos de almacenamiento según el tipo de columna”.
M indica la anchura máxima para
mostrar. La anchura máxima es 255. La anchura de muestra no
tiene nada que ver con el tamaño de almacenamiento o el rango
de valores que el valor puede contener, como se describe en
Sección 11.2, “Tipos numéricos”.
Si especifica ZEROFILL para columnas
numéricas,, MySQL añade automáticamente el atributo
UNSIGNED en la columna.
SERIAL es un alias para BIGINT
UNSIGNED NOT NULL AUTO_INCREMENT.
SERIAL DEFAULT VALUE en la definición de una
columna de tipo entero es un alias para NOT NULL
AUTO_INCREMENT UNIQUE.
Atención: Debe tener en cuenta
que cuando usa la resta entre valores enteros cuando uno de los
operandos es de tipo UNSIGNED, el resultado
no tiene signo. Consulte Sección 12.8, “Funciones y operadores de cast”.
BIT[(
M)]
En un tipo de datos bit. M indica
el número de bits por valor, de 1 a 64. El valor por
defecto es 1 si se omite M .
Este tipo de datos se añadió en MySQL 5.0.3 para
MyISAM, una extensión en 5.0.5 para
MEMORY, InnoDB, y
BDB. Antes de 5.0.3,
BIT es un sinónimo de
TINYINT(1).
TINYINT[(
M)] [UNSIGNED]
[ZEROFILL]
Un entero muy pequeño. El rango con signo es de
-128 a 127. El rango
sin signo es de 0 a
255.
BOOL, BOOLEAN
Son sinónimos para TINYINT(1). Un valor
de cero se considera falso. Valores distintos a cero se
consideran ciertos.
En el futuro, se introducirá tratamiento completo de tipos booleanos según el estándard SQL.
SMALLINT[(
M)] [UNSIGNED]
[ZEROFILL]
Un entero pequeño. El rango con signo es de
-32768 a 32767. El
rango sin signo es de 0 a
65535.
MEDIUMINT[(
M)]
[UNSIGNED] [ZEROFILL]
Entero de tamaño medio. El rango con signo es de
-8388608 a 8388607. El
rango sin singo es de 0 a
16777215.
INT[(
M)] [UNSIGNED]
[ZEROFILL]
Un entero de tamaño normal. El rango con signo es de
-2147483648 a
2147483647. El rango sin signo es de
0 a 4294967295.
INTEGER[(
M)] [UNSIGNED]
[ZEROFILL]
Es un sinónimo de INT.
BIGINT[(
M)] [UNSIGNED]
[ZEROFILL]
Un entero grande. El rango con signo es de
-9223372036854775808 a
9223372036854775807. El rango sin signo
es de 0 a
18446744073709551615.
Algunos aspectos a considerar con respecto a las columnas
BIGINT :
Toda la aritmética se hace usando valores
BIGINT o DOUBLE,
así que no debe usar enteros sin signos mayores que
9223372036854775807 (63 bits)
except con funciones bit! Si lo hace, algunos de los
últimos dígitos en el resultado pueden ser erróneos
por culpa de errores de redondeo al convertir valores
BIGINT a DOUBLE.
MySQL 5.0 puede tratar BIGINT en
los siguientes casos:
Cuando usa enteros para almacenar valores grandes
sin signo en una columna BIGINT
.
En
MIN(
o
col_name)MAX(,
donde col_name)col_name se
refiere a una columna BIGINT .
Al usar operadores (+,
-, *, y
así) donde ambos operadores son enteros.
Siempre puede guardar un valor entero exacto en un
columna BIGINT almacenándolo
usando una cadena de caracteres. En este caso, MySQL
realiza una conversión cadena de caracteres-número
que no implica representación de doble precisión
intermedia.
Los operadores -,
+, y * usan
BIGINT en operaciones aritméticas
cuando ambos operandos son valores enteros. Esto
significa que si multiplica dos enteros grandes (o
resultados de funciones que devuelven enteros), puede
obtener resultados inesperados cuando el resultado es
mayor que 9223372036854775807.
FLOAT(
p) [UNSIGNED]
[ZEROFILL]
Número con coma flotante. p
representa la precisión. Puede ir de 0 a 24 para números
de coma flotante de precisión sencilla y de 25 a 53 para
números de coma flotante con doble precisión. Estos tipos
son como los tipos FLOAT y
DOUBLE descritos a continuación.
FLOAT(p) tiene le mismo rango que los
tipos correspondientes FLOAT y
DOUBLE, pero la anchura de muestra y el
número de decimales no están definidos.
En MySQL 5.0, este es un valor de coma flotante auténtico.
Esta sintaxis se proprociona para compatibilidad con ODBC.
Usar FLOAT puede darle algunos problemas
inesperados ya que todos los cálculos se en MySQL se hacen
con doble precisión. Consulte
Sección A.5.7, “Resolver problemas con registros que no salen”.
FLOAT[(
M,D)]
[UNSIGNED] [ZEROFILL]
Un número de coma flotante pequeño (de precisión simple).
Los valores permitidos son de
-3.402823466E+38 a
-1.175494351E-38, 0, y
de 1.175494351E-38 a
3.402823466E+38. Si se especifica
UNSIGNED, los valores negativos no se
permiten. M es la anchura de
muestra y D es el número de
dígitos significativos. FLOAT sin
argumentos o
FLOAT(
(donde p)p está en el rango de 0 a
24) es un número de coma flotante con precisión simple.
DOUBLE[(
M,B)]
[UNSIGNED] [ZEROFILL]
Número de coma flotante de tamaño normal (precisión
doble). Los valores permitidos son de
-1.7976931348623157E+308 a
-2.2250738585072014E-308,
0, y de
2.2250738585072014E-308 a
1.7976931348623157E+308. Si se especifica
UNSIGNED, no se permiten valores
negativos. M es la anchura de
muestra y B es el número de bits
de precisión. DOUBLE sin parámetros o
FLOAT(
(donde p)p está en el rango de 25
a 53) es un número de coma flotante con doble precisión.
Un número de coma flotante con precision sencilla tiene una
precisión de 7 decimales aproximadamente; un número con
coma flotante de doble precisión tiene una precisión
aproximada de 15 decimales.
DOUBLE
PRECISION[(,
M,D)]
[UNSIGNED] [ZEROFILL]REAL[(
M,D)]
[UNSIGNED] [ZEROFILL]
Son sinónimos de DOUBLE. Excepción: Si
el modo del servidor SQL incluye la opción
REAL_AS_FLOAT, REAL es
un sinónimo para FLOAT en lugar de
DOUBLE.
DECIMAL[(
M[,D])]
[UNSIGNED] [ZEROFILL]
A partir de MySQL 5.0.3:
Número de punto fijo exacto y empaquetado.
M es el número total de dígitos
y D es el número de decimales.
El punto decimal y (para números negativos) el signo
'-' no se tiene en cuenta en
M. Si
D es 0, los valores no tienen
punto decimal o parte fraccional. El máximo número de
dígitos (M) para
DECIMAL es 64. El máximo número de
decimales soportados (D) es 30.
Si UNSIGNED se especifica, no se permiten
valores negativos.
Si se omite D, el valor por
defecto es 0. Si se omite M, el
valor por defecto es 10.
Todos los cálculos básicos (+, -, *, /)
con columnas DECIMAL se hacen con
precisión de 64 dígitos decimales.
Antes de MySQL 5.0.3:
Número de punto decimal fijo sin empaquetar. Se comporta
como una columna CHAR ; "sin
empaquetar" significa que el número se alacena como
una cadena de caracteres, usando un carácter para cada
dígito del valor. M es el
número total de dígitos y D es
el número de decimales. El punto decimal y (para números
negativos) el signo '-' no se cuenta en
M, aunque se reserva espacio para
él. Si D es 0, los valores no
tienen punto decimal ni parte fraccional. El máximo rango
de los valores DECIMAL es el mismo que
para DOUBLE, pero el rango real para una
columna DECIMAL dada puede estar
restringido por la elección de M
y D. Si se especifica
UNSIGNED no se permiten números
negativos.
Si se omite D, el valor por
defecto es 0. Si se omite M, el
valor por defecto es 10.
DEC[(,
M[,D])]
[UNSIGNED] [ZEROFILL]NUMERIC[(,
M[,D])]
[UNSIGNED] [ZEROFILL]FIXED[(
M[,D])]
[UNSIGNED] [ZEROFILL]
Son sinónimos para DECIMAL. El sinónimo
FIXED está disponible por compatibilidad
con otros servidores.
Un resumen de los tipos de columnas temporales se muestra a continuación. Para información adicional, consulte Sección 11.3, “Tipos de fecha y hora”. Los requerimientos de almacenamiento se dan en Sección 11.5, “Requisitos de almacenamiento según el tipo de columna”.
DATE
Una fecha. El rango soportado es de
'1000-01-01' a
'9999-12-31'. MySQL muestra valores
DATE en formato
'YYYY-MM-DD', pero permite asignar
valores a columnas DATE usando cadenas de
caracteres o números.
DATETIME
Combinación de fecha y hora. El rango soportado es de
'1000-01-01 00:00:00' a
'9999-12-31 23:59:59'. MySQL muestra
valores DATETIME en formato
'YYYY-MM-DD HH:MM:SS', pero permite
asignar valores a las columnas DATETIME
usando cadenas de caracteres o números.
TIMESTAMP[(
M)]
Una marca temporal. El rango es de '1970-01-01
00:00:00' hasta el año 2037.
Una columna TIMESTAMP es útil para
registrar la fecha y hora de una operación
INSERT o UPDATE . La
primera columna TIMESTAMP en una tabla se
rellena automáticamente con la fecha y hora de la
operación más reciente si no le asigna un valor. Puede
asignar a cualquier columna TIMESTAMP la
fecha y hora actual asignándole un valor
NULL .
En MySQL 5.0, TIMESTAMP se retorna como
una cadena de caracteres en el formato 'YYYY-MM-DD
HH:MM:SS' cuya anchura de muestra son 19
caracteres. Si quiere obtener el valor como un número,
debe añadir +0 a la columa timestamp .
TIME
Una hora. El rango es de '-838:59:59' a
'838:59:59'. MySQL muestra los valores
TIME en formato
'HH:MM:SS', pero permite asingar valores
a columnas TIME usando números o cadenas
de caracteres.
YEAR[(2|4)]
Un año en formato de dos o cuatro dígitos. El valor por
defecto está en formato de cuatro dígitos. En formato de
cuatro dígitos, los valores permitidos son de
1901 a 2155, y
0000. En formato de dos dígitos, los
valores permitidos son de 70 a
69, representando los años de 1970 a
2069. MySQL muestra los valores YEAR en
formato YYYY pero permite asignar valores
a columnas YEAR usando cadenas de
caracteres o números.
Un resumen de los tipos de columnas de cadenas de caracteres se muestra a continuación. Para información adicional, consulte Sección 11.4, “Tipos de cadenas de caracteres”. Los requerimientos de almacenamiento de estas columnas se dan en Sección 11.5, “Requisitos de almacenamiento según el tipo de columna”.
En algunos casos, MySQL puede cambiar una columna de cadena de
caracteres a un tipo diferente para un comando CREATE
TABLE o ALTER TABLE . Consulte
Sección 13.1.5.1, “Cambios tácitos en la especificación de columnas”.
Los tipos de cadenas de caracteres MySQL 5.0 incluyen algunas características que puede que no haya encontrado trabajando con versiones anteriores de MySQL anteriores a la 4.1:
Las definiciones de columnas para varios tipos de datos de
cadenas de caracteres incluyen un atributo
CHARACTER SET para especificar el
conjunto de caracteres y, ocasionalmente, una colación.
(CHARSET es sinónimo de
CHARACTER SET.) Estos atributos se
aplican a los tipos CHAR,
VARCHAR, TEXT,
ENUM, y SET. Por
ejemplo:
CREATE TABLE t
(
c1 CHAR(20) CHARACTER SET utf8,
c2 CHAR(20) CHARACTER SET latin1 COLLATE latin1_bin
);
Esta definición de tabla crea una columna llamada
c1 que tiene un conjunto de caracteres
utf8 con la colación por defecto para
ese conjunto de caracteres, y una columna llamada
c2 que tiene el conjunto de caracteres
latin1 y la colación binaria para el
conjunto de caracteres. La colación binaria no es sensible
a mayúsculas.
MySQL 5.0 interpreta las especificaciones de longitud en las definiciones de las columnas en unidades de caracteres . (En algunas versiones anteriores de MySQL la longitud se interpreta en bytes.)
Para los tipos CHAR,
VARCHAR, y the TEXT,
el atributo BINARY hace que se asigne a
la columna la colación binaria del conjunto de caracteres.
Las ordenaciones y comparaciones de las columnas de tipo
carácter se basan en el conjunto de caracteres asignado a
la columna. Para versiones anteriores, la comparación y
ordenación se basan en la colación del conjunto de
caracteres del servidor. Para columnas
CHAR y VARCHAR, puede
declarar que la columna con el atributo
BINARY realice la ordenación y la
comparación usando los códigos de los valores subyacentes
en lugar del orden léxico.
Para más información acerca del soporte de conjuntos de caracteres en MySQL 5.0, consulte Capítulo 10, Soporte de conjuntos de caracteres.
[NATIONAL] CHAR(
M)
[BINARY | ASCII | UNICODE]
Una cadena de caracteres de longitud fija que siempre tiene
el número necesario de espacios a la derecha para ajustarla
a la longitud especificada al almacenarla.
M representa la longitud de la
columna. El rango de M en MySQL
5.0 es de 0 a 255 caracteres.
Nota: Los espacios a la
derecha se borran cuando se obtiene los valores
CHAR .
Antes de MySQL 5.0.3, una columna CHAR
con una longitud especificada mayor que 255 se convierte al
tipo TEXT más pequeño que pueda tener
los valores de la longitud dada. Por ejemplo,
CHAR(500) se convierte a
TEXT, y CHAR(200000)
se convierte en MEDIUMTEXT. Esta es una
característica de compatibilidad. Sin embargo, esta
conversión causa que la columna tenga longitud variable, y
también afecta a la eliminación de espacios.
CHAR es una abreviatura para
CHARACTER. NATIONAL
CHAR (o su forma equivalente de,
NCHAR) es la forma estándard de SQL de
definir que una columna CHAR debe usar el
conjunto de caracteres por defecto. Este es el
comportamiento por defecto en MySQL.
El atributo BINARY es una abreviatura
para especificar la colación binaria del conjunto de
caracteres de la columna. La ordenación y comparación se
basa en los valores numéricos de los caracteres.
El tipo de columna CHAR BYTE es un alias
para CHAR BINARY. Esta es una
característica de compatibilidad.
El atributo ASCII puede especificarse
para CHAR. Asigna el conjunto de
caracteres latin1.
El atributo UNICODE puede especificarse
en MySQL 5.0 para CHAR. Asigna el
conjunto de caracteres ucs2 .
MySQL le permite crear un tipo de columna
CHAR(0). Esto es útil cuando tiene que
cumplir con las especificaciones de alguna aplicación vieja
que dependa de la existencia de una columna pero que no usa
realmente el valor. Esto es también útil cuando necesita
una columna que sólo pueda tener dos valores: Una columna
CHAR(0) que no esté definido como
NOT NULL ocupa sólo un bit y sólo puede
tener dos valores NULL y
'' (la cadena de caracteres vacía).
CHAR
Es un sinónimo de CHAR(1).
[NATIONAL] VARCHAR(
M)
[BINARY]
Cadena de caracteres de longitud variable.
M representa la longitud de
columna máxima. En MySQL 5.0, el rango de
M es de 0 a 255 antes de MySQL
5.0.3, y de 0 a 65,535 en MySQL 5.0.3 y posterior. (La
longitud máxima real de un VARCHAR en
MySQL 5.0 se determina por el tamaño de registro máximo y
el conjunto de caracteres que use. La longitud máxima
efectiva desde MySQL 5.0.3 es de 65,532
bytes.)
Nota: Antes de 5.0.3, los
espacios finales se eliminaban cuando se almacenaban los
valores VARCHAR, lo que difiere de le
especificación estándard de SQL.
Previo a MySQL 5.0.3, una columna VARCHAR
con una longitud especificada mayor a 255 se convertía al
valor de tipo TEXT más pequeño que
podía soportar el valor de la longitu dada. Por ejemplo,
VARCHAR(500) se convertía a
TEXT, y
VARCHAR(200000) se convertía a
MEDIUMTEXT. Esto era una cuestión de
compatibilidad. Sin embargo, esta conversión afectaba la
eliminación de espacios finales.
VARCHAR es la abreviación de
CHARACTER VARYING.
En MySQL 5.0, el atributo BINARY es
abreviatura para especificar la colación binaria del
conjunto de caracteres de la columna. La ordenación y la
comparación se basa en los valores numéricos de los
caracteres.
Desde MySQL 5.0.3, VARCHAR se guarda con
un prefijo de longitud de uno o dos bytes + datos. La
longitud del prefijo es de dos bytes si la columna
VARCHAR se declara con una longitud mayor
a 255.
BINARY(
M)
El tipo BINARY es similar al tipo
CHAR, pero almacena cadenas de datos
binarios en lugar de cadenas de caracteres no binarias.
VARBINARY(
M)
El tipo VARBINARY es similar al tipo
VARCHAR, pero almacena cadenas de
caracteres binarias en lugar de cadenas de caracteres no
binarias.
TINYBLOB
Una columna BLOB con una longitud máxima
de 255 (2^8 - 1) bytes.
TINYTEXT
Una columna TEXT con longitud máxima de
255 (2^8 - 1) caracteres.
BLOB[(
M)]
Una columna BLOB con longitud máxima de
65,535 (2^16 - 1) bytes.
Una longitud opcional M puede
darse para este tipo en MySQL 5.0. Si se hace, MySQL creará
las columnas como el tipo BLOB de tamaño
mínimo para tratar los valores de
M bytes.
TEXT[(
M)]
Una columna TEXT con longitud máxima de
65,535 (2^16 - 1) caracteres.
En MySQL 5.0, se puede dar una longitud opcional
M . En ese caso MySQL creará las
columnas con el tipo TEXT de longitud
mínima para almacenar los valors de longitud
M .
MEDIUMBLOB
Una columna BLOB con longitud de
16,777,215 (2^24 - 1) bytes.
MEDIUMTEXT
Una columna TEXT con longitud máxima de
16,777,215 (2^24 - 1) caracteres.
LONGBLOB
Una columna BLOB con longitud máxima de
4,294,967,295 o 4GB (2^32 - 1) bytes. La longitud máxima
efectiva (permitida) de las columnas
LONGBLOB depende del tamaño máximo
configurado para los paquetes en el protocolo
cliente/servidor y la memoria disponible.
LONGTEXT
Una columna TEXT con longitud máxima de
4,294,967,295 or 4GB (2^32 - 1) caracteres. La longitud
máxima efectiva (permitida) de
columnas LONGTEXT depende del tamaño
máximo de paquete configurado en el protocolo
cliente/servidor y la memoria disponible.
ENUM('
value1','value2',...)
Una enumeración. Un objeto de cadena de caracteres que
sólo puede tener un valor, elegido de una lista de valores
',
value1'',
value2'..., NULL o el valor
de error especial '' . Una columna
ENUM puede tener un máximo de 65,535
valores distintos. Los valores ENUM se
representan internamente como enteros.
SET('
value1','value2',...)
Un conjunto. Un objeto de cadena de caracteres que puede
tener cero o más valores que deben pertencer a la lista de
valores
',
value1'',
value2'... Una columna SET
puede tener un máximo de 64 miembros. Los valores
SET se representan internamente como
enteros.
MySQL soporta todos los tipos de datos SQL numéricos estándard.
Estos tipos incluyen los tipos numéricos exactos
(INTEGER, SMALLINT,
DECIMAL, y NUMERIC), así
como los tipos de datos aproximados (FLOAT,
REAL, y DOUBLE PRECISION).
La palabra clave INT es sinónimo de
INTEGER, y la palabra clave
DEC es sinónimo de DECIMAL.
En MySQL 5.0.3, un tipo de datos BIT está
disponible para almacenar valores de un bit. (Antes de 5.0.3,
MySQL interpreta BIT como
TINYINT(1).) En MySQL 5.0.3,
BIT lo soporta sólo tablas
MyISAM. MySQL 5.0.5 extiende soporte de
BIT para MEMORY,
InnoDB, y BDB.
Como extensión de los estándards SQL, MySQL soporta los tipos
enteros TINYINT, MEDIUMINT,
y BIGINT. La siguiente tablas muestra el
almacenamiento requerido y el rango para cada uno de los tipos
enteros.
| Tipo | Bytes | Valor Mínimo | Valor Máximo |
| (Con signo/Sin signo) | (Con signo/Sin signo) | ||
TINYINT | 1 | -128 | 127 |
0 | 255 | ||
SMALLINT | 2 | -32768 | 32767 |
0 | 65535 | ||
MEDIUMINT | 3 | -8388608 | 8388607 |
0 | 16777215 | ||
INT | 4 | -2147483648 | 2147483647 |
0 | 4294967295 | ||
BIGINT | 8 | -9223372036854775808 | 9223372036854775807 |
0 | 18446744073709551615 |
MySQL soporta otra extensión para especificar de forma óptima el
ancho a mostrar de un tipo entero en paréntesis después de la
palabra clave para el tipo (por ejemplo,
INT(4)). Esta especificación opcional del
ancho de muestra se usa para alinear a la izquierda la muestra de
los valores con ancho menor que el ancho especificado para la
columna.
El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.
Cuando se usa en conjunción con el atributo de extensión
opcional ZEROFILL, el relleno por defecto de
espacios se replaza por ceros. Por ejmplo, para una columna
declarada como INT(5) ZEROFILL, un valor de
4 se muestra como 00004.
Tenga en cuenta que si almacena valores mayores que el ancho de
muestra en una columna entera, puede tener problemas cuando MySQL
genera tablas temporales para algunos joins complicados, ya que en
estos casos MySQL cree que los datos encajan en el ancho original
de la columna.
Todos los tipos enteros pueden tener un atributo opcional (no
estándard) UNSIGNED. Los valores sin signo
pueden usarse cuando quiere permitir sólo números no negativos
en una columna y necesita un rango numérico mayor para la
columna.
Tipos de coma flotante y de coma fija pueden ser
UNSIGNED. Como con los tipos enteros, este
atributo evita que los valores negativos se almacenen en la
columna. Sin embargo, a diferencia de los tipos enteros, el rango
superior de los valores de la columna sigue siendo el mismo.
Si especifica ZEROFILL para una columna
numérica, MySQL añade automáticamente el atributo
UNSIGNED a la columna.
Para columnas de tipo coma flotante, MySQL usa cuatro bytes para valores de precisión simple y ocho bytes para valores de doble precisión.
El tipo FLOAT se usa para representar tipos
numéricos aproximados. El estándard SQL permite una
especificación opcional de la precisión (pero no del rango del
exponente) en bits a continación de la palabra clave
FLOAT entre paréntesis. La implementación de
MySQL soporta esta especificación opcional de precisión, pero el
valor de precisión se usa sólo para determinar el tamaño de
almacenamiento. Una precisión de 0 a 23 resulta en una columna de
precisión simple de cuatro bytes de tamaño
FLOAT . Una precisión de 24 a 53 resulta en
una columna de doble precisión de ocho bytes de tamaño
DOUBLE .
Cuando se especifica la palaba clave FLOAT para
tipos de columnas sin especificar la precisión, MySQSL usa cuatro
bytes para almacenar los valors.MySQL también soporta una
sintaxis alternativa con dos números entre paréntesis a
continación de la palabra clave FLOAT . El
primer número representa el ancho a mostrar y el segundo número
especifica el número de dígitos a almacenar a continuación del
punto decimal ( como con DECIMAL y
NUMERIC). Cuando se pide a MySQL que almacene
un número para tales columnas con más dígitos decimales a
continuación del punto decimal del especificado para la columna,
el valor se redondea para elminar los dígitos extras cuando se
almacena el valor.
En SQL estándard, los tipos REAL y
DOUBLE PRECISION no aceptan especificaciones de
precisión. MySQL soporta una sintaxis alternativa con dos
números dados entre paréntesis a continuación del nombre del
tipo. El primer número representa el ancho a mostrar y el segundo
número especifica el número de dígitos a almacenar y mostrar a
continuación del punto decimal. Como una extensión al estándard
SQL, MySQL reconoce DOUBLE como sinónimo del
tipo DOUBLE PRECISION . En contraste con el
requerimiento estándard que la precisión para
REAL sea menor que la usada para
DOUBLE PRECISION, MySQL implementa ambas como
valores de punto flotante de doble precisión con tamaño de ocho
bytes (a no ser que el modo SQL del servidor incluya la opción
REAL_AS_FLOAT ).
Para portabilidad máxima, el código que requiera almacenamiento
de datos numéricos aproximados debe usar FLOAT
o DOUBLE PRECISION sin especificar la
precisión ni el número de dígitos decimales.
Los tipos DECIMAL y NUMERIC
se implementan como el mismo tipo en MySQL. Se usan para guardar
valores para los que es importante preservar una precisión
exacta, por ejemplo con datos monetarios. Cuando se declara una
columna de alguno de estos tipos, la precisión y la escala puede
especificarse (y usualmente se hace), por ejemplo:
salary DECIMAL(5,2)
En este ejemplo, 5 es la precisión y
2 es la escala. La precisión representa el
número de dígitos decimales significativos que se almacenan para
los valores, y la escala representa el número de dígitos que
pueden almacenarse a continuación del punto decimal.
Desde MySQL 5.0.3, los valores DECIMAL y
NUMERIC se almacenan en formato binario. Antes
de 5.0.3, MySQL almacena los valores DECIMAL y
NUMERIC como cadenas de caracteres, en lugar
de binario. .Un carácter se usa para cada dígito del valor, el
punto decimal (si la escala es mayor que 0), y el signo
'-' (para números negativos). Si la escala es
0, los valores DECIMAL y
NUMERIC no contienen punto decimal o parte
fraccional.
SQL estándard requiere que la columna salary
sea capaz de almacenar cualquier valor con cinco dígitos y dos
decimales. En este caso, por lo tanto, el rango de valores que
puede almacenarse en la columna salary es desde
-999.99 a 999.99. MySQL
fuerza este límite desde MySQL 5.0.3. Antes de 5.0.3, MySQL 5.0
variaba este límite de forma que, en el límite positivo del
rango, la columna podía almacenar números hasta
9999.99. (Para números positivos, MySQL 5.0.2
y anteriores usaba el byte reservado para el signo para extender
el límite superior del rango.)
En SQL estándard, la sintaxis
DECIMAL( es
equivalente a
M)DECIMAL(.
Similarmente, la sintaxis M,0)DECIMAL es
equivalente a
DECIMAL(, donde
la implementación se permite para decidir el valor de
M,0)M. Ambas formas de los tipos
DECIMAL y NUMERIC se
soportan en MySQL 5.0. El valor por defecto de
M es 10.
El máximo rango de los valores DECIMAL y
NUMERIC es el mismo para
DOUBLE, pero el rango real para un valor dado
en una columna DECIMAL o
NUMERIC puede restringirse con la precisión o
escala para una columna dada. Cuando en tal columna se asigna un
valor con más dígitos siguiendo el punto decimal de los
permitidos por la escala específica, el valor se convierte a tal
escala. (El comportamiento preciso depende del sistema operativo,
pero generalmente el efecto es que se trunca al número de
dígitos permitidos.)
Desde MySQL 5.0.3, el tipo de datos BIT puede
usarse para guardar valores de un bit. Un tipo
BIT( permite el
almacenamiento de valores de M)M-bit .
M tiene un rango de 1 a 64.
Para especificar valores bit, puede usar la notación
b' .
value'value es un valor binario escrito
usando ceros y unos. Por ejemplo, b'111' y
b'100000000' representan 7 y 128,
respectivamente. Consulte Sección 9.1.5, “Valores de bits”.
Si asigna un valor a una columna
BIT( con menos de
M)M bits , el valor se alinea a la
izquierda con ceros. Por ejemplo, asignar un valor
b'101' a una columna BIT(6)
es, en efecto, lo mismo que asignar b'000101'.
Cuando se intenta almacenar un valor en una columna numérica que está fuera del rango permitido por la columna, MySQL corta el valor en el final del rango permitido y guarda el valor resultante.
Por ejemplo, el ranto de una coluna INT es de
-2147483648 a 2147483647. Si
intenta insertar -9999999999 en una columna
INT, MySQL reemplaza el valor con el mínimo
valor del rango y almacena -2147483648 en su
lugar. De forma similar, si trata de insertar
9999999999, MySQL reemplaza el valor con el
valor máximo del rango y almacena 2147483647
en su lugar.
Si la columna INT es
UNSIGNED, el tamaño del rango de la columna es
el mismo, pero los límites cambian a 0 y
4294967295. Si intenta almacenar
-9999999999 y 9999999999,
los valores almacenados en la columna son 0 y
4294967296.
Cuando se asigna un valor fuera de rango especificado (o por defecto) a una columna de coma flotante o fija, MySQL almacena el valor representado por el valor correspondiente al límite de rango correspondiente.
Las conversiones debidas a valores fuera de rango se reportan como
advertencias para los comandos ALTER TABLE,
LOAD DATA INFILE, UPDATE, y
INSERT de múltiples registros.
Los tipos de fecha y hora para representar valores temporales son
DATETIME, DATE,
TIMESTAMP, TIME, y
YEAR. Cada tipo temporal tiene un rango de
valores legales, así como un valor “zero” que se usa
cuando se especifica un valor ilegal que MySQL no puede
representar. El tipo TIMESTAMP tiene un
comportamiento automático especial, descrito posteriormente.
Desde MySQL 5.0.2, MySQL da advertencias/errores si trata de
insertar una fecha ilegal. Puede hacer que MySQL acepte ciertas
fechas, tales como '1999-11-31', usando el modo
SQL ALLOW_INVALID_DATES . (Antes de 5.0.2, este
modo era el comportamiento por defecto de MySQL). Esto es útil
cuando quiere almacenar el valor “posiblemente
erróneo” que el usuario especifica (por ejemplo, en un
formulario web) en la base de datos para un posterior
procesamiento. En este modo, MySQL sólo verifica que el mes esté
en el rango de 0 a 12 y que el día esté en el rango de 0 a 31.
Estos rangos incluyen cero ya que MySQL permite almacenar fechas
cuando el día o el mes son cero en columnas
DATE o DATETIME . Esto es
muy útil para aplicaciones que necesiten almacenar una fecha de
nacimiento para la que no sepa la fecha exacta. En este caso,
símplemente almacena la fecha como
'1999-00-00' o '1999-01-00'.
Si almacena valores similares a estos, no debe esperar obtener
resultados correctos para funciones tales como
DATE_SUB() or DATE_ADD que
necesitan fechas completas. (Si no quiere permitir ceros en las
fechas, puede usar el modo SQL NO_ZERO_IN_DATE
).
MySQL permite almacenar '0000-00-00' como
“fecha de pruebas” (si no está usando el modo SQL
NO_ZERO_DATE ). Esto es mejor que usar (y usa
menos espacio de datos e índice) que usar valores
NULL .
Modificando la variable de sistema sql_mode al
modo apropiado, puede especificar exactamente qué tipos de datos
quiere soportar con MySQL. Consulte
Sección 5.3.2, “El modo SQL del servidor”.
Aquí hay algunas consideraciones generales a tener en cuenta cuando se trabaja con tipos de fecha y hora:
MySQL muestra los valores para una fecha o hora en un formato de salida estándard, pero trata de intepretar una variedad de formatos para los valores de entrada que se proporcionan (por ejemplo, cuando especifica un valor para asignar o comparar con un tipo fecha o hora). Sólo los formatos descritos en las siguientes secciones son soportados. Se espera la entrada de valores legales. Si se usan otros formatos pueden ocurrir resultados imprevisibles.
Las fechas con años de dos dígitos son ambituas, ya que no se sabe el siglo. MySQL interpreta los años de dos dígitos usando las siguientes reglas:
Los años del rango 70-99 se convierten
en 1970-1999.
Los años del rango 00-69 se convierten
en 2000-2069.
Aunque MySQL trata de interpretar los valores con varios
formatos, las fechas siempre deben darse en el orden
año-mes-día (por ejemplo, '98-09-04'), en
lugar del formato mes-día-año o día-mes-año usados
comunmente (por ejemplo, '09-04-98',
'04-09-98').
MySQL convierte automáticamente una fecha o hora a un número si el valor se usa en un contexto numérico y viceversa.
Cuando MySQL encuentra un valor para fecha o hora que está
fuera de rango o es ilegal para el tipo (como se describe al
inicio de la sección), lo convierte al valor
“cero” para ese tipo. La excepción es que los
valores fuera de rango del tipo TIME se
reemplazan por el valor límite de rango apropiado para el
tipo TIME .
La siguiente tabla muestra el formato del valor
“cero” para cada tipo. Tenga en cuenta que el uso
de estos valores produce mensajes de advertencia si el modo
SQL NO_ZERO_DATE está activado.
| Tipo de Columna | “Cero” Valor |
DATETIME | '0000-00-00 00:00:00' |
DATE | '0000-00-00' |
TIMESTAMP | 00000000000000 |
TIME | '00:00:00' |
YEAR | 0000 |
Los valores “cero” son especiales, pero puede
almacenarlos o referirse a ellos explícitamente usando los
valores mostrados en la tabla. También puede hacerlo usando
los valores '0' o 0, que
son más sencillos de escribir.
Los valores de fecha o hora “cero” usados a
través de MyODBC se convierten automáticamente a
NULL en MyODBC 2.50.12 y posterior, ya que
ODBC no puede tratar estos valores.
Los tipos DATETIME, DATE,
and TIMESTAMP están relacionados. Esta
sección describe sus características, en que se parecen y en
que difieren.
El tipo DATETIME se usa cuando necesita
valores que contienen información de fecha y hora. MySQL recibe
y muestra los valores DATETIME en formato
'YYYY-MM-DD HH:MM:SS' . El rango soportado es
de '1000-01-01 00:00:00' a
'9999-12-31 23:59:59'.
(“Soportado” significa que aunque valores
anteriores pueden funcionar, no hay garantías)
El tipo DATE se usa cuando necesita sólo un
valor de fecha, sin una parte de hora. MySQL recibe y muestra
los valores DATE en formato
'YYYY-MM-DD' . El rango soportado es de
'1000-01-01' a
'9999-12-31'.
El tipo TIMESTAMP tiene varias propiedades,
en función de la versión de MySQSL y el modo SQL que esté
ejecutando el servidor. Estas propiedades se describen
posteriormente en esta sección.
Puede especificar valores DATETIME,
DATE, y TIMESTAMP usando
cualquier de los siguientes formatos:
Como cadena de caracteres en formato 'YYYY-MM-DD
HH:MM:SS' o 'YY-MM-DD HH:MM:SS'
. Una sintaxis “relajada” se permite: Cualquier
carácter de puntuación puede usarse como delimitador entre
partes de fecha o de hora. Por ejemplo, '98-12-31
11:30:45', '98.12.31 11+30+45',
'98/12/31 11*30*45', y '98@12@31
11^30^45' son equivalentes.
Como cadena de caracteres en formato
'YYYY-MM-DD' or
'YY-MM-DD' . Se permite una sintaxis
“relajada” . Por ejemplo,
'98-12-31',
'98.12.31',
'98/12/31', y
'98@12@31' son equivalentes.
Como cadena de caracteres sin delimitadores en formato
'YYYYMMDDHHMMSS' o
'YYMMDDHHMMSS', mientras que la cadena de
caracteres tenga sentido como fecha. Por ejemmplo,
'19970523091528' y
'970523091528' se interpretan como
'1997-05-23 09:15:28', pero
'971122129015' es ilegal (tiene una parte
de minutos sin sentido) y se convierte en
'0000-00-00 00:00:00'.
Como cadena de caracteres sin delimitadores en formato
'YYYYMMDD' o 'YYMMDD'
, mientras que el cadena de caracteres tenga sentido como
fecha. Por ejemplo, '19970523' y
'970523' se interpretan como
'1997-05-23', pero
'971332' es ilegal (tiene una parte de
mes y día sin sentido) y se convierte en
'0000-00-00'.
Como número en formato YYYYMMDDHHMMSS o
YYMMDDHHMMSS, mientras que el número
tenga sentido como fecha. Por ejemplo,
19830905132800 y
830905132800 se interpretan como
'1983-09-05 13:28:00'.
Como número en formato YYYYMMDD o
YYMMDD, mientras que el número tenga
sentido como fecha. Por ejemplo, 19830905
y 830905 se interpretan como
'1983-09-05'.
Como resultado de una función que retorne un valor
acceptable en un contexto DATETIME,
DATE, o TIMESTAMP ,
como NOW() o
CURRENT_DATE.
Los valores ilegales de DATETIME,
DATE, o TIMESTAMP se
convierten al valor “cero” del tipo apropiado
('0000-00-00 00:00:00',
'0000-00-00', o
00000000000000).
Para valores especificados como cadenas de caracteres que
incluyan partes de fecha delimitadas, no es necesario
especificar dos dígitos para valores de mes o día menores que
10. '1979-6-9' es lo mismo
que '1979-06-09'. Similarmente, para valores
especificados como cadenas de caracteres que incluyan
delimitadores para la parte de hora, no es necesario especificar
dos dígitos para horas, minutos o segundos menores que
10. '1979-10-30 1:2:3' es
lo mismo que '1979-10-30 01:02:03'.
Los valores especificados como números deben tener una longitud
de 6, 8, 12, o 14 dígitos. Si un número tiene una longitud de
8 o 14 dígitos, se asume que está en formato
YYYYMMDD o YYYYMMDDHHMMSS
y que el año lo dan los primeros 4 dígitos. Si el número
tiene 6 o 12 dígitos de longitud, se asume que está en formato
YYMMDD o YYMMDDHHMMSS y
que el año lo dan los primeros 2 dígitos. Los números que no
tengan estas longitudes se interpretan como si tuvieran ceros a
la izquierda y fueran de la longitud permitida más cercana.
Los valores especificados como cadenas de caracteres no
delimitadas se interpretan usando su longitud. Si la cadena de
caracteres tiene longitud 8 o 14, el año se asume como dado
por los primeros 4 caracteres. En el resto de caso, se supone
que el año lo dan los primeros 2 caracteres. La cadena de
caracteres se interpreta de izquierda a derecha para encontrar
el año, mes, día, hora, minuto y segundo, para tantas partes
como representa la cadena de caracteres. Esto significa que no
debe usar cadenas de caracteres con menos de 6 caracteres. Por
ejemplo, si especifica '9903', pensando que
representa Marzo, 1999, MySQL inserta un valor
“cero” en la tabla. Esto es porque el valor de año
y mes son 99 y 03, pero la
parte de día no se encuentra, así que el valor no es una fecha
legal. Sin embargo, puede especificar explícitamente un valor
de cero para representar partes de día y mes. Por ejemplo,
puede usar '990300' para insertar el valor
'1999-03-00'.
Puede asignar valores de un tipo a un objeto de un tipo diferente hasta un límite. Sin embargo, hay algunas alteraciones del valor o pérdidas de información:
Si asigna un valor DATE a un objeto
DATETIME o TIMESTAMP,
la parte de hora del valor resultante se cambia a
'00:00:00' ya que el valor
DATE no contiene información temporal.
Si asigna un valor DATETIME o
TIMESTAMP a un objeto
DATE, la parte temporal del valor
resultante se borra porque el tipo DATE
no tiene información temporal.
Tenga en cuenta que aunque DATETIME,
DATE, y TIMESTAMP
pueden especificarse usando el mismo conjunto de formatos,
los tipos no tienen el mismo rango de valores. Por ejemplo,
TIMESTAMP no pueden ser anteriores a
1970 o posteriores a
2037. Esto significa que una fecha como
'1968-01-01', que sería legal como
DATETIME o DATE no es
un valor válido TIMESTAMP y se convierte
a 0 si se asigna a un objeto de este
tipo.
Tenga en cuenta ciertas cosas al especificar valores temporales:
El formato relajado para valores especificados como cadenas
de caracteres puede ser problemático. Por ejemplo, un
valor como '10:11:12' puede parecer una
hora por el delimitador ':' , pero si se
usa en un contexto de fecha se interpreta como
'2010-11-12'. El valor
'10:45:15' se convierte a
'0000-00-00' ya que
'45' no es un mes legal.
El servidor MySQL realiza sólo chequeo básico de la
validez de las fechas: Los rangos para año, mes y día son
de 1000 a 9999, 00 a 12, y 00 a 31, respectivamente.
Cualquier fecha que contenga partes fuera de estos rangos
está sujeta a conversión a
'0000-00-00'. Tenga en cuenta que esto
permite almacenar fechas inválidas como
'2002-04-31'. Para asegurar que una fecha
es válida, haga una comprobación en su aplicación.
Fechas con valores de año de dos dígitos son ambíguas porque no se conoce el siglo. MySQL interpreta los años de dos dígitos usando las siguientes reglas:
Los valores de años en el rango
00-69 se convierten a
2000-2069.
Los valores de años en el rango
70-99 se convierten a
1970-1999.
Nota: En antiguas versiones
de MySQL (antes de la 4.1), las propiedades de las columnas
TIMESTAMP difieren significativamente en
muchas cosas de lo que se describe en esta sección. Si
necesita convertir datos TIMESTAMP antiguos
para que funcionen con MySQL 5.0, asegúrese de consultar
Manual de referencia de MySQL 4.1 para más detalles.
En MySQL 5.0, TIMESTAMP se muestran en el
mismo formato que las columnas DATETIME. En
otras palabras, el ancho de muestra se limita a 19
caracteres, y el formato es YYYY-MM-DD
HH:MM:SS.
El servidor MySQL puede ejecutarse en modo
MAXDB . Cuando el servidor corre en este
modo, TIMESTAMP es idéntico a
DATETIME. Esto es, si el servidor está
ejecutándose en modo MAXDB cuando se crea
una tabla, las columnas TIMESTAMP se crean
como columnas DATETIME . Como resultado,
tales columnas usan el formato de salida de
DATETIME, tienen el mismo rango de valores,
y no hay inicialización automática o actualización de la
fecha y hora actual.
Para activar el modo MAXDB, cambie el modo
SQL del servido aMAXDB cuando arranque
usando la opción --sql-mode=MAXDB o
cambiando en tiempo de ejecución la variable global
sql_mode:
mysql> SET GLOBAL sql_mode=MAXDB;
Un cliente puede hacer que el servidor se ejecute en modo
MAXDB para sus propias conexiones como se
muestra:
mysql> SET SESSION sql_mode=MAXDB;
Desde MySQL 5.0.2, MySQL no acepta valores timestamp que
incluyan cero en la columna de día o hora o valores que no
sean fechas válidas. La única excepción es el valor
especial '0000-00-00 00:00:00'.
En MYSQL 5.0, tiene considerable flexibilidad para determinar
cuando se actualiza e inicializa automáticamente
TIMESTAMP y qué columna debe tener ese
comportamiento:
Puede asignar la fecha y hora actual como el valor por defecto y el valor de actualización automático, como se hacía anteriormente. Pero es posible tener sólo uno u otro comportamiento automático, o ninguno de ellos. (No es posible tener un comportamiento para una columna y el otro para la otra columna.)
Puede especificar qué columna
TIMESTAMP inicializar o actualizar con
la fecha y hora actuales. Ya no hace falta que sea la
primera columna TIMESTAMP .
Tenga en cuenta que la información en la siguiente discusión
se aplica a columnas TIMESTAMP sólo para
tablas no creadas con el modo MAXDB
activado. (Como se menciona anteriormente, el modo
MAXDB hace que las columnas se creen como
columnas DATETIME .) Las reglas que
gobiernan la inicialización y actualización de columnas
TIMESTAMP en MySQL 5.0 son las siguientes:
Si un valor DEFAULT se especifica para
la primera columna TIMESTAMP en una
tabla, no se ignora. El valor por defecto puede ser
CURRENT_TIMESTAMP o una fecha y hora
constante.
DEFAULT NULL es lo mismo que
DEFAULT CURRENT_TIMESTAMP para la
primera columna
TIMESTAMP. Para cualquier otra columna
TIMESTAMP, DEFAULT
NULL se trata como DEFAULT 0.
Cualquier columna TIMESTAMP individual
en una tabla puede actualizarse e inicializarse con la
fecha y hora actual automáticamente.
En un comando CREATE TABLE, la primera
columna TIMESTAMP puede declararse de
cualquiera de las siguientes formas:
Con las cláusulas DEFAULT
CURRENT_TIMESTAMP y ON UPDATE
CURRENT_TIMESTAMP, la columna tiene la fecha
y hora actual como su valor por defecto, y se
actualiza automáticamente.
Sin las cláusulas DEFAULT ni
ON UPDATE, es lo mismo que
DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP.
Con la cláusula DEFAULT
CURRENT_TIMESTAMP y sin ON
UPDATE, la columna tiene la fecha y hora
actual como valor por defecto pero no se actualiza
automáticamente.
Sin cláusula DEFAULT y con
cláusula ON UPDATE
CURRENT_TIMESTAMP, la columna tiene por
defecto 0 y se actualiza automáticamente.
Con un valor constante DEFAULT, la
columna tiene el valor dado por defecto. Si la columna
tiene una cláusula ON UPDATE
CURRENT_TIMESTAMP se actualiza
automáticamente, de otro modo no lo hace.
En otras palabras, puede usar la fecha y hora actuales
para el valor inicial y el valor de actualización
automática, o uno de ellos o ninguno. (Por ejemplo, puede
especificar ON UPDATE para activar
actualización automática sin tener la columna
inicializada .)
Cualquiera de CURRENT_TIMESTAMP,
CURRENT_TIMESTAMP(), o
NOW() puede usarse en las cláusulas
DEFAULT y ON UPDATE
. Todas tienen el mismo efecto.
El orden de los dos atributos no importa. Si se
especifican DEFAULT y ON
UPDATE para una columna
TIMESTAMP, cualquiera puede preceder al
otro.
Ejemplo. Estos comandos son equivalentes:
CREATE TABLE t (ts TIMESTAMP); CREATE TABLE t (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP); CREATE TABLE t (ts TIMESTAMP ON UPDATE CURRENT_TIMESTAMP DEFAULT CURRENT_TIMESTAMP);
Para especificar el valor por defecto o actualización
automática para una columna TIMESTAMP
distinta a la primera, debe suprimir la actualización e
inicialización automática de la primera columna
TIMESTAMP asignándole explícitamente
una valor constante DEFAULT (por
ejemplo, DEFAULT 0 o DEFAULT
'2003-01-01 00:00:00'). Luego, para la otra
columna TIMESTAMP, las reglas son las
mismas que para la misma columna
TIMESTAMP, excepto que no puede omitir
ambas cláusulas DEFAULT y ON
UPDATE . Si lo hace, no habrá inicialización
ni actualización automática.
Ejemplo, estos comandos son equivalentes:
CREATE TABLE t (
ts1 TIMESTAMP DEFAULT 0,
ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP);
CREATE TABLE t (
ts1 TIMESTAMP DEFAULT 0,
ts2 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
DEFAULT CURRENT_TIMESTAMP);
En MySQL 5.0, puede asignar la zona horaria actual para cada
conexión, como se describe en
Sección 5.9.8, “Soporte de zonas horarias en el servidor MySQL”. Los valores
TIMESTAMP se almacenan en UTC,
convirtiéndose desde la zona horaria actual para
almacenamiento, y volviéndose a convertir a la zona horaria
actual al mostrarse. Mientras la zona horaria permanezca
constante, puede obtener el mismo valor que hay almacenado. Si
almacena un valor TIMESTAMP, cambia la zona
horaria y luego rescata el valor, es diferente que el valor
almacenado. Esto ocurre porque no se usa la misma zona horaria
para la conversión en ambas direcciones. La zona horaria
actual está disponible en la variable de sistema
time_zone.
Puede incluir el atributo NULL en la
definición de una columna TIMESTAMP para
permitir que la columna contenga valores
NULL . Por ejemplo:
CREATE TABLE t ( ts1 TIMESTAMP NULL DEFAULT NULL, ts2 TIMESTAMP NULL DEFAULT 0, ts3 TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP );
Si el atributo NULL no se especifica,
asignar el valor NULL a la columna resulta
en que se almacena la hora y fecha actuales. Tenga en cuenta
que una columna TIMESTAMP que permita
valores NULL
no no almacenará la fecha y
hora actual a no ser que su valor por defecto se defina como
CURRENT_TIMESTAMP,
o NOW() o
CURRENT_TIMESTAMP se inserte en la columna.
En otras palabras, una columna TIMESTAMP
definida como NULL se actualizará
automáticamente sólo si se crea usando una definición como
las siguientes:
CREATE TABLE t (ts NULL DEFAULT CURRENT_TIMESTAMP);
De otro modo - esto es, si la columna
TIMESTAMP se define usando
NULL pero no usando DEFAULT
TIMESTAMP, como se muestra aquí...
CREATE TABLE t1 (ts NULL DEFAULT NULL); CREATE TABLE t2 (ts NULL DEFAULT '0000-00-00 00:00:00');
...entonces debe insertar el valor explícitamente correspondiente a la fecha y hora actuales. Por ejemplo:
INSERT INTO t1 VALUES (NOW()); INSERT INTO t2 VALUES (CURRENT_TIMESTAMP);
MySQL devuelve y muestra los valores TIME en
formato 'HH:MM:SS' (o formato
'HHH:MM:SS' para valores de hora grandes).
TIME tiene rango de
'-838:59:59' a
'838:59:59'. La razón por la que la parte de
hora puede ser tan grande es que el tipo TIME
puede usarse no sólo para representar una hora del día (que
debe ser menor a 24 horas), pero también el tiempo transcurrido
o un intervalo de tiempo entre dos eventos (que puede ser mucho
mayor a 24 horas, o incluso negativo).
Puede especificar valores TIME en una
variedad de formatos:
Como cadena de caracteres en formato 'D
HH:MM:SS.fracción'. También puede usar una de
las siguientes sintaxis “relajadas” :
'HH:MM:SS.fracción',
'HH:MM:SS', 'HH:MM',
'D HH:MM:SS', 'D
HH:MM', 'D HH', o
'SS'. Aquí D
representa días y puede tener un valor de 0 a 34. Tenga en
cuenta que MySQL no almacena la fracción (todavía).
Como cadena de caracteres sin delimitadores en formato
'HHMMSS', mientras que tenga sentido como
hora. Por ejemplo, '101112' se entiende
como '10:11:12', pero
'109712' es ilegal (no tiene una parte de
minutos correcta) y pasa a ser
'00:00:00'.
Como número en formato HHMMSS, mientras
tenga sentido como hora. Por ejemplo,
101112 se entiende como
'10:11:12'. Los siguientes formatos
alternativos también se entienden: SS,
MMSS, HHMMSS,
HHMMSS.fracción. Tenga en cuenta que
MySQL no almacena la fracción (todavía).
Como resultado de una función que retorna un valor que es
aceptable en un contexto TIME, tal como
CURRENT_TIME.
Para valores TIME especificados como cadenas
de caracteres que incluyan un delimitador de las partes de
hora, no es necesario especificar dos dígitos para horas,
minutos o segundos que tengan un valor inferior a
10. '8:3:2' es lo mismo
que '08:03:02'.
Tenga cuidado con asignar valores abreviados a una columna
TIME . Sin comas, MySQL interpreta los
valores asumiendo que los dos dígitos más a la derecha
representan segundos. (MySQL interpreta valores
TIME como tiempo transcurrido en lugar de
horas del día.) Por ejemplo puede pensar que
'1112' y 1112 significan
'11:12:00' (12 minutos tras las 11 en punto),
pero MySQL los interpreta como '00:11:12' (11
minutos, 12 segundos). Similarmente, '12' y
12 se interpretan como
'00:00:12'. Los valores
TIME con comas, por contrario, se tratan
siempre como hora del día. Esto es, '11:12'
significa '11:12:00', no
'00:11:12'.
Los valores fuera del rango de TIME pero que
son legales se cambian por el valor límite de rango más
cercano. Por ejemplo '-850:00:00' y
'850:00:00' se convierten en
'-838:59:59' y
'838:59:59'.
Valores TIME ilegales se convierten a
'00:00:00'. Tenga en cuenta que como
'00:00:00' es un valor
TIME legal, no hay forma de decir si un valor
'00:00:00' almacenado en una tabla, se
insertó como '00:00:00' o como valor ilegal.
El tipo YEAR es un tipo de un byte usado para
representar años.
MySQL devuelve y muestra los valores YEAR en
formato YYYY . El rango es de
1901 a 2155.
Puede especificar los valores YEAR en una
variedad de formatos:
Como cadena de caracteres de cuatro dígitos en el rango de
'1901' a '2155'.
Como número de cuatro dígitos en el rango de
1901 a 2155.
Como cadena de caracteres de dos dígitos en el rango de
'00' a '99'. Los
valores en los rangos de '00' a
'69' y de '70' a
'99' se convierten en valores
YEAR en el rango de
2000 a 2069 y de
1970 a 1999.
Como número de dos dígitos en el rango de
1 a 99. Los valores en
los rangos de 1 a 69 y
de 70 a 99 se
convierten en valores YEAR en los rangos
de 2001 a 2069 y de
1970 a 1999. Tenga en
cuenta que el rango para números de dos dígitos es
ligeramente distinto del rango para cadenas de caracteres
de dos dígitos, ya que no especifica el cero directamente
como número y tiene que ser interpretado como
2000. Debe especificarlo como cadena de
caracteres '0' o '00'
o se interpreta como 0000.
Como resultado de una función que retorne un valor que se
acepte en un contexto YEAR, como
NOW().
Valores YEAR ilegales se convierten en
0000.
MySQL no tiene problemas con el año 2000 (Y2K) (consulte Sección 1.4.5, “Conformidad con el efecto 2000”), pero los valores de entrada presentados a MySQL pueden tenerlos. Cualquier entrada con valores de años de dos dígitos es ambigua, ya que no se conoce el siglo. Tales valores deben interpretarse en forma de cuatro dígitos, ya que MySQL los almacena internamente usando cuatro dígitos.
Para tipos DATETIME, DATE,
TIMESTAMP, y YEAR, MySQL
interpreta las fechas con valores de año ambíguos usando las
siguientes reglas:
Años en el rango 00-69 se convierten a
2000-2069.
Años en el rango 70-99 se convierten a
1970-1999.
Recuerde que estas reglas proporcionan sólo suposiciones razonables sobre lo que significan los valores. Si el heurístico usado por MySQL no produce los valores correctos, debe proporcionar entrada no ambígua con años de cuatro dígitos.
ORDER BY ordena valores
TIMESTAMP o YEAR
correctamente que tengan años de dos digitos.
Algunas funciones como MIN() y
MAX() convierten un
TIMESTAMP o YEAR a
número. Esto significa que un valor con un año de dos dígitos
no funciona correctamente con estas funciones. En este caso la
solución es convertir TIMESTAMP o
YEAR a formato de cuatro dígitos o usar algo
como MIN(DATE_ADD(timestamp,INTERVAL 0
DAYS)).
Los tipos de cadenas de caracteres son CHAR,
VARCHAR, BINARY,
VARBINARY, BLOB,
TEXT, ENUM, y
SET. Esta sección describe cómo funcionan
estos tipos y cómo usarlo en sus consultas.
Los tipos CHAR y VARCHAR
son similares, pero difieren en cómo se almacenan y recuperan.
Desde MySQL 5.0.3, también difieren en la longitud máxima y en
cómo se tratan los espacios finales.
Los tipos CHAR y VARCHAR
se declaran con una longitud que indica el máximo número de
caracteres que quiere almacenar. Por ejemplo,
CHAR(30) puede almacenar hasta 30
caracteres.
La longitud de una columna CHAR se fija a la
longitud que se declara al crear la tabla. La longitud puede ser
cualquier valor de 0 a 255. Cuando los valores
CHAR se almacenan, se añaden espacios a la
derecha hasta las longitud específica. Cuando los valores
CHAR se recuperan, estos espacios se borran.
Los valores en columnas VARCHAR son cadenas
de caracteres de longitud variable. En MySQL 5.0, la longitud
puede especficarse de 0 a 255 antes de MySQL 5.0.3, y de 0 a
65,535 en 5.0.3 y versiones posteriores. (La máxima longitud
efectiva de un VARCHAR en MySQL 5.0 se
determina por el tamaño de registro máximo y el conjunto de
caracteres usados. La longitud máxima total es de 65,532
bytes.)
En contraste con CHAR,
VARCHAR almacena los valores usando sólo los
caracteres necesarios, más un byte adicional para la longitud
(dos bytes para columnas que se declaran con una longitud
superior a 255).
Los valores VARCHAR no se cortan al
almacenarse. El tratamiento de espacios al final depende de la
versión. Desde MySQL 5.0.3, los espacios finales se almacenan
con el valor y se retornan, según el estándard SQL. Antes de
MySQL 5.0.3, los espacios finales se eliminan de los valores
cuando se almacenan en una columna VARCHAR,
esto significa que los espacios también están ausentes de los
valores retornados.
Durante el almacenamiento y la recuperación de valores no hace ninguna conversión de mayúsculas y minúsculas.
Si asigna un valor a una columna CHAR o
VARCHAR que exceda la longitud máxima de la
columna, el valor se trunca. Si los caracteres truncados no son
espacios, se genera una advertencia. Puede hacer que aparezca un
error en lugar de una advertencia usando modo SQL estricto.
Consulte Sección 5.3.2, “El modo SQL del servidor”.
Antes de MySQL 5.0.3, si necesita un tipo de datos para el que
no se borren los espacios finales, considere usar un tipo
BLOB o TEXT . También, si
quiere almacenar valores binarios como resultados de
encriptación o compresión que puedan contener valores byte
arbitrarios, use una columna BLOB en lugar de
CHAR o VARCHAR, para
evitar problemas potenciales con eliminación de espacios
finales que puedan cambiar los valores de los datos.
La siguiente tabla ilustra las diferencias entre los dos tipos
de columnas mostrando el resultado de almacenar varios valores
de cadenas de caracteres en columnas CHAR(4)
y VARCHAR(4) :
| Valor | CHAR(4) | Almacenamiento necesario | VARCHAR(4) | Almacenamiento necesario |
'' | ' ' | 4 bytes | '' | 1 byte |
'ab' | 'ab ' | 4 bytes | 'ab' | 3 bytes |
'abcd' | 'abcd' | 4 bytes | 'abcd' | 5 bytes |
'abcdefgh' | 'abcd' | 4 bytes | 'abcd' | 5 bytes |
Los valores retornados de las columnas
CHAR(4) y VARCHAR(4) son
los mismos en cada caso, ya que los espacios finales se eliminan
en la recuperación de valores CHAR.
En MySQL 5.0, los valores en columnas CHAR y
VARCHAR se almacenan y comparan según la
colación del conjunto de caracteres asignado a la columna.
CHAR BYTE es un alias para CHAR
BINARY. Existe por cuestión de compatibilidad.
El atributo ASCII asigna el conjunto de
caracteres latin1 a una columna
CHAR . El atributo UNICODE
asigna el conjunto de caracteres ucs2 .
MySQL puede cambiar silenciosamente el tipo de una columna
CHAR o VARCHAR en tiempo
de creación. Consulte Sección 13.1.5.1, “Cambios tácitos en la especificación de columnas”.
Los tipos BINARY y
VARBINARY son similares a
CHAR y VARCHAR, excepto
que contienen cadenas de caracteres binarias en lugar de
cadenas de caracteres no binarias. Esto es, contienen cadenas
de bytes en lugar de cadenas de caracteres. Esto significa que
no tienen conjunto de caracteres asignado, y la comparación y
ordenación se basa en los valores numéricos de los valores de
los bytes.
La longitud máxima disponible es la máxima para
BINARY t VARBINARY como
para CHAR y VARCHAR,
excepto que la longitud para BINARY y
VARBINARY es una longitud en bytes en lugar
de en caracteres.
El tratamiento de los espacios finales es el mismo para
BINARY y VARBINARY como lo
es para CHAR y VARCHAR.
Cuando se almacenan los valores BINARY, se
rellenan con espacios a la derecha hasta la longitud
especificada. Cuando los valores BINARY se
recuperan, los espacios finales se eliminan. Para
VARBINARY, los espacios finales se eliminan
cuando los valores se almacenan. Desde MySQL 5.0.3, los espacios
finales se mantienen. Debe considerar estas características si
planea usar estos tipos de datos para almacenar datos binarios
que deban acabar con espacios.
En MySQL 5.0, BINARY y
VARBINARY son tipos de datos distintos. Para
CHAR( y
M) BINARYVARCHAR(,
el atributo M) BINARYBINARY hace que se use la
colación binaria para la columna, pero la columna no contiene
cadenas de caracteres no binarios en lugar de cadenas binarias
de bytes. Por ejemplo CHAR(5) BINARY se trata
como CHAR(5) CHARACTER SET latin1 COLLATE
latin1_bin, asumiendo que el conjunto de caracteres
por defecto es latin1.
Un BLOB es un objeto binario que puede tratar
una cantidad de datos variables. Los cuatro tipos
BLOB son TINYBLOB,
BLOB, MEDIUMBLOB, y
LONGBLOB. Difieren sólo en la longitud
máxima de los valores que pueden tratar.
Los cuatro tipos TEXT son
TINYTEXT, TEXT,
MEDIUMTEXT, y LONGTEXT. Se
corresponden a los cuatro tipos BLOB y tienen
las mismas longitudes y requerimientos de almacenamiento.
Consulte Sección 11.5, “Requisitos de almacenamiento según el tipo de columna”.
Las columnas BLOB se tratan como cadenas de
caracteres binarias (de bytes). Las columnas
TEXT se tratan como cadenas de caracteres no
binarias (de carácateres). Las columnas BLOB
no tienen conjunto de caracteres, y la ordenación y la
comparación se basan en los valores numéricos de los bytes.
Las columnas TEXT tienen un conjunto de
caracteres y se ordenan y comparan en base de la colación del
conjunto de caracteres asignada a la columna desde MySQL 4.1.
No hay conversión de mayúsculas/minúsculas para columnas
TEXT o BLOB durante el
almacenamiento o la recuperación.
Si asiguna un valor a una columna BLOB o
TEXT que exceda la longitud máxima del tipo
de la columna, el valor se trunca. Si los caracteres truncados
no son espacios, aparece una advertencia. Puede hacer que
aparezca un error en lugar de una advertencia usando el modo SQL
estricto. Consulte