Ejemplo de tipos de datos de Mariadb CONNECT

El controlador CONNECT se introdujo en MariaDB 10.0.

Muchos tipos de datos tienen poco o ningún sentido cuando se aplican a archivos sin formato. Esta es la razón por la que CONNECT admite solo un conjunto restringido de tipos de datos. Sin embargo, las tablas de origen ODBC, JDBC o MYSQL pueden contener tipos de datos no admitidos por CONNECT. En este caso, CONNECT realiza una conversión automática a un tipo compatible similar cuando es posible.

Los tipos de datos admitidos actualmente por CONNECT son:

TYPE_STRING

Este tipo corresponde a lo que generalmente se conoce como CHAR o VARCHAR por los usuarios de la base de datos, o como cadenas por los programadores. Las columnas que contienen caracteres tienen una longitud máxima, pero la cadena de caracteres es de longitud fija o variable según el formato del archivo.

La opción DATA_CHARSET debe usarse para especificar el juego de caracteres usado en la fuente de datos o archivo. Tenga en cuenta que, a diferencia de lo que suele ocurrir con MariaDB, cuando se utiliza un conjunto de caracteres de varios bytes, el tamaño de la columna representa el número de bytes que puede contener el valor de la columna, no el número de caracteres.

TYPE_INT

El tipo]INTEGER contiene valores de 4 bytes numéricos enteros con signo (el int / del lenguaje C) que van desde –2,147,483,648 para 2,147,483,647 para tipo firmado y 0 para 4,294,967,295 para el tipo sin firmar.

TYPE_SHORT

El tipo de datos SHORT contiene valores de 2 bytes numéricos enteros con signo (el entero corto del lenguaje C) que van desde –32,768 para 32,767 para tipo firmado y 0 para 65,535 para el tipo sin firmar.

TYPE_TINY

El tipo de datos TINY contiene valores enteros numéricos de 1 byte (el carbonizarse del lenguaje C) que van desde –128 para 127 para tipo firmado y 0 para 255 para el tipo sin firmar. Para algunos tipos de tablas, TYPE_TINY se usa para representar valores booleanos (0 es falso, cualquier otra cosa es verdadera).

TYPE_BIGINT

El tipo de datos BIGINT contiene valores enteros de 8 bytes con signo (el largo largo del lenguaje C) que van desde -9,223,372,036,854,775,808 para 9,223,372,036,854,775,807 para tipo firmado y de 0 para 18,446,744,073,709,551,615 para el tipo sin firmar.

Dentro de las tablas, la codificación de todos los valores enteros depende del tipo de tabla. En las tablas representadas por archivos de texto, el número se escribe en caracteres, mientras que en las tablas representadas por archivos binarios (BIN o VEC) el número se almacena directamente en la representación binaria correspondiente a la plataforma.

los largo (o precisión) la especificación corresponde a la longitud del campo de la tabla en el que se almacena el valor solo para archivos de texto. Se utiliza para establecer la longitud del campo de salida para todos los tipos de tablas.

TYPE_DOUBLE

El tipo de datos DOBLE corresponde al tipo doble del lenguaje C, un valor de doble precisión de punto flotante codificado con 8 bytes. Al igual que para los enteros, la codificación interna de las tablas depende del tipo de tabla, los caracteres de los archivos de texto y la representación binaria de la plataforma para los archivos binarios.

los largo La especificación corresponde a la longitud del campo de la tabla en el que se almacena el valor solo para archivos de texto. los escala (era precisión) es el número de dígitos decimales escritos en archivos de texto. Para los tipos de tablas binarias (BIN y VEC) esto no se aplica. los largo y escala Las especificaciones se utilizan para establecer la longitud del campo de salida y el número de decimales para todos los tipos de tablas.

TYPE_DECIM

El tipo de datos DECIMAL corresponde a lo que las fuentes de datos MariaDB u ODBC llaman NUMBER, NUMERIC o DECIMAL: un valor numérico con un número máximo de dígitos (la precisión), algunos de los cuales eventualmente son dígitos decimales (la escala). La codificación interna en CONNECT es una representación de caracteres del número. Por ejemplo:

colname decimal(14,6)

Esto define una columna colname como un número que tiene un precisión de 14 y un escala de 6. Suponiendo que esté poblado por:

insert into xxx values (-2658.74);

La representación interna de la misma será la cadena de caracteres. -2658.740000. La forma en que se almacena en una tabla de archivos depende del tipo de tabla. los largo La especificación del campo corresponde a la longitud del campo de la tabla en el que se almacena el valor y lo calcula CONNECT a partir del precisión y el escala valores. Esta longitud es precisión más 1 si escala no es 0 (para el punto decimal) más 1 si esta columna no está sin signo (para el eventual signo menos). En tablas con formato fijo, el número se justifica a la derecha en el campo de ancho largo, para tablas con formato variable, como CSV, el campo es la cadena de caracteres que la representa.

Debido a que CONNECT utiliza principalmente este tipo para manejar campos numéricos o decimales de tipos de tablas ODBC, JDBC y MySQL, CONNECT no proporciona cálculos ni comparaciones decimales por sí mismo. Esta es la razón por la que las columnas decimales de las tablas CONNECT no se pueden indexar.

FECHA Tipo de datos

Internamente, CONNECT almacena los valores de fecha / hora como un entero de 4 bytes con signo. El valor 0 corresponde al 1 de enero de 1970 12:00:00 am hora universal coordinada (UTC). Todos los demás valores de fecha / hora están representados por el número de segundos transcurridos desde o antes de la medianoche (00:00:00), 1 de enero de 1970, hasta ese valor de fecha / hora. Los valores de fecha / hora anteriores a la medianoche del 1 de enero de 1970 se representan mediante un número negativo de segundos.

CONNECT maneja fechas desde 13 de diciembre de 1901, 20:45:52 para 18 de enero de 2038, 19:14:07.

Aunque la información de fecha y hora se puede representar en tipos de datos CHAR e INTEGER, el tipo de datos DATE tiene propiedades asociadas especiales. Para cada valor de FECHA, CONNECT puede almacenar toda o solo parte de la siguiente información: siglo, año, mes, día, hora, minuto y segundo.

Formato de fecha en tablas de texto

Internamente, los valores de fecha / hora se manejan como un entero de 4 bytes con signo. Pero en las tablas de texto (tipo DOS, FIX, CSV, FMT y DBF) las fechas se almacenan la mayor parte del tiempo como una cadena de caracteres formateada (aunque también se pueden almacenar como una cadena numérica que representa su valor interno). Debido a que hay infinitas formas de formatear una fecha, el formato que se utilizará para decodificar las fechas, así como la longitud del campo en el archivo, debe estar asociado a las columnas de fecha (excepto cuando se almacenan como el valor numérico interno).

Tenga en cuenta que este formato asociado se usa solo para describir la forma en que el valor temporal se almacena internamente. Este formato se utiliza tanto para la salida para decodificar la fecha en una instrucción SELECT como para la entrada para codificar la fecha en las instrucciones INSERT o UPDATE. Sin embargo, lo que se mantiene en este valor depende del tipo de datos utilizado en la definición de la columna (se pueden especificar todos los valores temporales de MariaDB). Al crear una tabla, el formato se asocia a una columna de fecha usando la opción DATE_FORMAT en la definición de la columna, por ejemplo:

create table birthday (
  Name varchar(17),
  Bday date field_length=10 date_format='MM/DD/YYYY',
  Btime time field_length=8 date_format='hh:mm tt')
engine=CONNECT table_type=CSV;

insert into birthday values ('Charlie','2012-11-12','15:30:00');

select * from birthday;

La consulta SELECT devuelve:

Los valores de la instrucción INSERT deben especificarse utilizando la sintaxis estándar de MariaDB y estos valores se muestran como valores temporales de MariaDB. Efectivamente, los formatos de columna se aplican solo a la forma en que estos valores se representan dentro de los archivos CSV. Aquí, el registro insertado será:

Charlie,11/12/2012,03:30 PM

Nota: La opción field_length existe porque la sintaxis MariaDB no permite especificar la longitud del campo entre paréntesis para los tipos de columnas temporales. Si no se especifica, la longitud del campo se calcula a partir del formato de fecha (a veces como un valor máximo) o se iguala al valor de longitud predeterminado si no hay formato de fecha. En el ejemplo anterior, podría haberse eliminado ya que los valores calculados son los especificados. Sin embargo, si el tipo de tabla hubiera sido DOS o FIX, estos valores podrían ajustarse para ajustarse a la longitud real del campo dentro del archivo.

Una cadena de formato CONNECT consta de una serie de elementos que representan un dato particular y definen su formato. Los elementos se reconocerán en el orden en que aparecen en la cadena de formato. Los elementos de formato de fecha y hora serán reemplazados por la fecha y hora reales tal como aparecen en la cadena de origen. Están definidos por los siguientes grupos de caracteres:

Notas de uso

• Para que coincida con la cadena de origen, puede agregar el texto del cuerpo a la cadena de formato, encerrándola entre comillas simples o comillas dobles si resulta ambiguo. No es necesario citar los signos de puntuación.
• La información de la hora se considera como formato de 12 horas si un elemento “t” o “tt” sigue al elemento “hh” en el formato o como formato de 24 horas en caso contrario.
• Los elementos “MM”, “DD”, “hh”, “mm”, “ss” se pueden especificar con una o dos letras (p. Ej., “MM” o “M”) sin importar la entrada, pero colocando un cero a la izquierda. a valores de un dígito en la salida^[1] para elementos de dos letras.
• Si el formato contiene elementos DDD o DDDD, el nombre del día de la semana se omite en la entrada y se ignora para calcular el valor de fecha interno. En la salida, se genera y muestra el nombre correcto del día de la semana.
• Los valores temporales siempre se almacenan como numéricos en las tablas BIN y VEC.

Manejo de fechas que están fuera del rango de fechas CONNECT admitidas

Si desea crear una tabla que contenga, por ejemplo, fechas históricas que no se pueden convertir en fechas CONNECT, haga su columna CHAR o VARCHAR y almacene las fechas en el formato MariaDB. Todas las funciones de fecha aplicadas a estas cadenas las convertirán a fechas MariaDB y funcionarán como si fueran fechas reales. Por supuesto, deben insertarse y se mostrarán utilizando el formato MariaDB.

Manejo NULO

CONECTAR manijas valores nulos para fuentes de datos capaces de producir nulos. Actualmente, esto concierne principalmente a los tipos de tabla ODBC, JDBC, MONGO, MYSQL, XML, JSON e INI. Para los tipos INI, JSON, MONGO o XML, los valores nulos se devuelven cuando falta la clave en la sección (INI) o cuando el nodo correspondiente no existe en una fila (XML, JSON, MONGO).

Para otras tablas de archivos, el problema es definir qué es un valor nulo. En una columna numérica, 0 a veces puede ser un valor válido pero, en otros casos, puede no tener sentido. Lo mismo para las columnas de caracteres; ¿Es un campo en blanco un valor válido o no?

Un caso especial son las columnas DATE con un DATE_FORMAT especificado. Cualquier valor que no coincida con el formato puede considerarse NULO.

CONNECT deja la decisión a usted. Al declarar una columna en la declaración CREATE TABLE, si se declara NOT NULL, los valores en blanco o cero se considerarán valores válidos. De lo contrario, se considerarán valores NULL. En todos los casos, los nulos se reemplazan al insertar o actualizar por valores pseudo nulos, una cadena de caracteres de longitud cero para los tipos de texto o un valor cero para los tipos numéricos. Una vez convertidos a valores pseudo-nulos, serán reconocidos como NULL solo para las columnas declaradas como anulables.

Por ejemplo:

create table t1 (a int, b char(10)) engine=connect;
insert into t1 values (0,'zero'),(1,'one'),(2,'two'),(null,'???');
select * from t1 where a is null;

La consulta de selección responde:

Efectivamente, el valor 0 ingresado en la primera fila se considera NULL para una columna que acepta valores NULL. Sin embargo, si ejecutamos la consulta:

select * from t1 where a = 0;

Esto no devolverá ninguna línea porque un NULL no es igual a 0 en una cláusula where de SQL.

Ahora veamos qué sucede con las columnas no nulas:

create table t1 (a int not null, b char(10) not null) engine=connect;
insert into t1 values (0,'zero'),(1,'one'),(2,'two'),(null,'???');

La declaración de inserción producirá una advertencia que dice:

Se reemplaza por un pseudo nulo 0 en la cuarta fila. Veamos el resultado:

select * from t1 where a is null;
select * from t1 where a = 0;

La primera consulta no devuelve filas, 0 son valores válidos y no NULL. La segunda consulta responde:

Muestra que el valor insertado NULL fue reemplazado por un valor 0 válido.

Tipos numéricos sin signo

Son compatibles con CONNECT desde la versión 1.01.0010 para tipos numéricos fijos (TINY, SHORT, INTEGER y BITINT).

Conversión de tipo de datos

CONNECT puede convertir datos de un tipo a otro en la mayoría de los casos. Estas conversiones se realizan sin previo aviso, incluso cuando esto conduce a un truncamiento o pérdida de precisión. Esto es cierto, en particular, para tablas de tipo ODBC, JDBC, MYSQL y PROXY (a través de MySQL) porque la tabla de origen puede contener algunos tipos de datos no admitidos por CONNECT. Se convierten cuando es posible en tipos CONNECT.

Cuando se convierten, los tipos MariaDB se convierten como:

En el caso de las columnas TEXT, el manejo depende de los valores dados a las variables de sistema connect_type_conv y connect_conv_size. De forma predeterminada, no se permite ninguna conversión.

Nota: BLOB no se convierte actualmente de forma predeterminada hasta que se agrega un tipo TYPE_BIN a CONNECT. Sin embargo, la opción FORCE (de Connect 1.06.006) se puede especificar para columnas de blobs que contienen texto y la opción SKIP también se aplica a las columnas BLOB de ODBC.

Los tipos ODBC SQL se convierten como:

Los tipos de JDBC SQL se convierten como:

Nota: La opción connect_type_conv SKIP también se aplica a las tablas ODBC y JDBC.

1. ↑ Aquí la entrada y la salida se utilizan para especificar respectivamente decodificar la fecha para obtener su valor numérico del archivo de datos y codificar una fecha para escribirla en el archivo de tabla. La entrada se realiza dentro de las consultas SELECT; la salida se realiza en consultas UPDATE o INSERT.

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.