Administrar los tipos de datos

Cuando cambie el tipo de datos o el tamaño del tipo de datos de una columna, esto puede tener implicaciones en las tareas que utilicen ese conjunto de datos.

Los tipos de datos admitidos y las conversiones varían según la plataforma de destino. Para obtener documentación específica para su plataforma de destino , consulte Creación de conexiones con destinos.

Entender el impacto de cambiar un tipo de datos

Hay dos casos de uso habituales en los que se pretende cambiar el tamaño del tipo de datos o cambiar a un tipo de datos diferente:

• Ingesta de datos que no tienen cabida en el tipo de datos actual.
• La exigencia de una mayor exactitud numérica. Por ejemplo, cambiar SMALLINT a DECIMAL (p,s).

En la mayoría de los casos, el cambio de un tipo de datos dará lugar a una operación ALTER TABLE, evitando así la pérdida de datos. Por ejemplo, si el tipo de datos anterior era STRING (25) y el nuevo es STRING (50), los datos de la columna con el nuevo tipo de datos se actualizarán sin ningún problema. Sin embargo, en algunos casos, el cambio de un tipo de datos hará que se elimine la tabla y se vuelva a crear. Por ejemplo, si el tipo de datos de la columna anterior es NUMBER y lo cambia a DATE, la tabla se eliminará y se volverá a crear, ya que no es posible convertir números en fechas. Del mismo modo, si la plataforma de destino no admite operaciones de tabla ALTER (como Databricks), la tabla se eliminará y se volverá a crear.

Hay algunos casos en los que teóricamente es posible alterar una tabla, pero debido a la complejidad subyacente, la tarea de datos la abandonará y volverá a crearla. Por último, hay casos en los que la pérdida potencial de datos, y no la pérdida real, desencadenará una operación de eliminar y volver a crear. Por ejemplo, si cambia STRING(25) por STRING(1), se producirá una pérdida de datos si los datos ingestados no caben en STRING(1). Sin embargo, es posible que STRING(25) contenga siempre un solo carácter, por lo que en la práctica no se producirá ninguna pérdida de datos, pero la tabla se eliminará y se volverá a crear debido a la posible pérdida de datos.

Cambios en los tipos de datos que requieren que la tabla se elimine y se vuelva a crear, independientemente de la plataforma de destino.

El cambio de los siguientes tipos de datos hará que se elimine la tabla y se vuelva a crear:

• BYTES
• BLOB
• CLOB
• NCLOB

Plataformas objetivo que admiten cambios en el tamaño de los tipos de datos sin necesidad de eliminar y volver a crear la tabla

Cuando trabaje con Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server y Azure Synapse Analytics, podrá modificar el tamaño de determinados tipos de datos sin que la tabla se elimine y se vuelva a crear. La tabla siguiente indica qué tipos de datos son compatibles con cada una de las plataformas mencionadas.

Plataformas objetivo que admiten el cambio de tipos de datos a STRING sin que la tabla se elimine y se vuelva a crear

Al mover datos a Microsoft SQL Server y Azure Synapse Analytics, puede cambiar los siguientes tipos de datos a STRING, sin que la tabla se elimine y se vuelva a crear:

• BOOLEAN
• DATE
• TIME
• DATETIME
• INT1
• INT2
• INT4
• INT8
• REAL4
• REAL8
• UINT1
• UINT2
• UNIT4
• UNIT8
• NUMERIC
• WSTRING (compatible solo con Azure Synapse Analytics)

Administrar datos JSON

Qlik introdujo la compatibilidad con el tipo de datos JSON en 2025. La compatibilidad con el tipo de datos JSON no está disponible en las tareas creadas antes de dicha introducción. En las nuevas tareas, las columnas con datos JSON se convertirán al tipo de datos especificado para la plataforma de destino. Se necesita Data Movement gateway 2024.11.78 o superior para descubrir el tipo de datos JSON en las tareas de destino si utiliza una pasarela administrada por el cliente.

Cuando se convierten datos JSON, pueden crearse estas nuevas reglas de transformación globales.

• QLIK__PARSE_TO_JSON

  Esta regla se crea en los proyectos de Snowflake en los que el destino o aterrizaje está cargando datos en el lago de destino. La regla se añade en la tarea de almacenamiento tras el aterrizaje para analizar sintácticamente todas las columnas JSON a JSON en Snowflake.

• QLIK__JSON_AS_VARCHAR

  Esta regla se crea en los proyectos de Snowflake en los que los datos aterrizan en Snowflake y el almacenamiento crea tablas Iceberg administradas por Snowflake. La regla convierte JSON a Varchar ya que Iceberg no admite el tipo Variant.

Administrar datos JSON existentes en tareas creadas antes de que se introdujera la compatibilidad con tipos de datos JSON

• Si tiene tareas actuales con datos JSON, VARIANT o SUPER en la plataforma de datos convertidos a otro tipo de datos, por ejemplo BLOB, puede considerar convertir las columnas al tipo de datos utilizado para JSON en la plataforma de destino. Puede realizarlo con una regla de transformación. Esto puede ser necesario si necesita utilizar columnas nuevas junto con columnas existentes en tareas posteriores.

• Otra opción es convertir las columnas de la nueva tarea al mismo tipo de datos utilizado en los tipos de datos existentes para mantener la compatibilidad con versiones anteriores.