#SQL

Digamos que tengo una clase persistente en IRIS con una propiedad opcional EmailOptIn:

Class Person Extends %Persistent
{
Property Name As %String;
Property EmailOptIn As %Boolean;
}

Más tarde me doy cuenta de que estoy haciendo muchas comprobaciones nulas en esta propiedad donde no debería ser necesario. La solución es hacer de esto una propiedad requerida:

¡Hola desarrolladores!

A veces necesitamos insertar o referir los datos de clases directamente en globals.

Y quizá muchos de vosotros esperáis que la estructura de datos de una global con registros sea:

^Sample.Person(Id)=$listbuild("",col1,col2,...,coln).

Este artículo es un aviso de que esto no siempre es verdad, así que no se debe dar por supuesto!

Encontrar errores en tu código o examinar un comportamiento inesperado es el principal objetivo de la depuración.

Trataré de actualizar las herramientas tradicionales aparte de las ayudas que tienen Studio, VScode, Serenji... Las herramientas básicas que han estado ahí antes de que tu EDI preferido lo utilizara en segundo plano.

Gracias a @Yuri Marx hemos visto un buen ejemplo de Migración de Bases de datos de Postgres a IRIS.
Mi problema personal es el uso de DBeaver como una herramienta de migración.
En especial, como una de las fortalezas de IRIS (y también Caché) es la disponibilidad de los SQLgateways que permiten el acceso a cualquier base de datos externa, siempre y cuando se puedan acceder usando ODBC/JDBC. Así que he ampliado el paquete para demostrarlo.

Una de nuestras apps utiliza una consulta de clase para un informe ZEN y funciona perfectamente en ese informe, produciendo los resultados esperados. Hemos migrado a InterSystems Reports y nos hemos dado cuenta de que, para un informe que utiliza la misma consulta de clase, aparecen en la parte de abajo más de 100 filas extra con los mismos valores en las columnas.

Descartamos InterSystems Reports como fuente del problema reproduciendo el problema de "filas extra" con una hoja de cálculo de Excel que llama a la misma consulta de clase utilizando un procedimiento almacenado.

¿Cuál era el problema? Cuando llamábamos al procedimiento almacenado desde el antiguo ZEN Report o desde la función SQL Query en el Portal de Administración, no veíamos estas filas adicionales.

¡Hola desarrolladores!

Como probablemente sabéis, en IRIS 2021 los nombres de los globals son aleatorios.

Y si creas clases de IRIS con DDL y quieres estar seguro de qué global se creó, seguramente te gustaría darle un nombre.

De hecho, se puede hacer.

Usa WITH %CLASSPARAMETER DEFAULTGLOBAL='^GLobalName' en la Tabla CREATE para que funcione. Documentación. Mirad este ejemplo:

Si defines una tabla/clase persistente, el compilador de clases genera una definición de almacenamiento adecuada. Otra opción es definir un mapeo SQL para un almacenamiento global que ya existe. Esto ya se explicó estupendamente en otra serie de artículos: El arte del mapeo de globales para Clases 1 de 3

En este artículo demostraré lo siguiente:

• Cómo actualizar ReferencesRange (OBX: 7) contra ObservationIdentifier (OBX: 3.1) [TestCode] de la base de datos mediante la función de utilidad personalizada
• Cómo actualizar Abnormal Flag (OBX: 8) contra ObservationIdentifier (OBX: 3.1) [TestCode] y ObservationValue (OBX: 5) [Resultado] desde la función de utilidad de base de datos
• Mensaje de ruta basado en un Abnormal Flag (OBX: 8)

Este es un ejemplo de código que funciona en IRIS 2020.1 y en Caché 2018.1.3 
No se mantendrá sincronizado con las nuevas versiones.      
Y NO cuenta con el servicio de soporte de InterSystems.

En la mayoría de los casos, un global que se utiliza como almacenamiento predeterminado tiene solo 1 nivel de subíndice que representa el IDKEY.
Para un índice de globals podemos ver 2 o más niveles de subíndices.
Las matrices, las relaciones de herencia padre hijo o las clases persistentes que extienden una clase base, son ejemplos en los que vemos más niveles. Aunque todos estos globals son bastante uniformes.

¡Hola desarroladores!

¿Os parece que las consultas sobre el rango de fechas son demasiado lentas? ¿Os parece que el rendimiento de SQL es bajo? ¡Tengo un curioso truco que podría ayudaros a solucionar estos problemas! (¡Los desarrolladores de SQL odian que sepáis estas cosas!)*

Si tenéis una clase que guarda los registros de hora cuando se añaden datos, entonces esos datos se ordenarán con vuestros valores IDKEY, es decir, TimeStamp₁ < TimeStamp₂ si y solo si la condición ID₁ < ID₂ se cumple para todos los valores ID y TimeStamp en la tabla - entonces podéis utilizar esta información para aumentar el rendimiento de las consultas en relación con los rangos de TimeStamp. Echad un vistazo a la siguiente tabla:

En los buenos tiempos, calcular el tamaño de los datos, flujos e índices para una clase/tabla era fácil - solo había que ejecutar %GSIZE y revisar los globals D, S, e I, respectivamente.

Sin embargo, hoy en día el sharding, los nombres de los globals optimizados y los índices en globals separados producen una salida %GSIZE parecida a esta:

En este artículo voy a mostrar los resultados de una comparación entre IRIS y Postgress manejando datos Astronómicos.

Introducción

Desde siempre el cielo nocturno nos ha fascinado. Todos hemos soñado con las estrellas y la posibilidad de que haya vida en otros planetas.

El orden es una necesidad para todos, pero no todos lo entienden de la misma manera (Fausto Cercignani)

Nota de traducción: este articulo se publicó originalmente basado en Caché. Para esta traducción se revisó todo el contenido usando InterSystems IRIS.

Descargo de responsabilidad: En este artículo se utilizan el ruso y el alfabeto cirílico como ejemplos, pero esto solamente es importante para las personas que utilizan InterSystems IRIS en lugares en los que no se habla inglés. Ten en cuenta que este artículo se refiere principalmente a las compilaciones de NLS, que son diferentes a las compilaciones de SQL. Las compilaciones en SQL (por ejemplo, SQLUPPER, SQLSTRING, EXACT que significa que no hay compilación, TRUNCATE, etc.) son funciones reales que se aplican de manera explícita a algunos valores, y cuyos resultados a veces se almacenan explícitamente en los subíndices de los *globals. De hecho, cuando se almacenan en subíndices, de forma natural estos valores seguirían la compilación de NLS (“Compilaciones de SQL y NLS”).*

Hay tres aspectos muy importantes en cualquier conversación sobre el rendimiento de SQL: los Índices, el TuneTable, y el Plan de ejecución. En los PDFs adjuntos a este artículo se incluyen presentaciones antiguas sobre estos temas. En los enlaces a nuestra documentación debajo, se ofrece más información sobre estos y otros asuntos relacionados con el rendimiento de SQL. La formación online también refuerza varios de estos temas. Además, hay varios artículos de la Comunidad de Desarrolladores que están relacionados con el rendimiento de SQL y que mostramos a continuación.

Hay bastantes repeticiones en la información que se muestra a continuación. Los aspectos más importantes a considerar sobre el rendimiento de SQL son:

• Los tipos de índices que están disponibles
• Por qué utilizar un tipo de índice en lugar de otro
• La información que TuneTable recaba para crear una tabla y lo que esto significa para Optimizer
• Cómo leer un Plan de ejecución para comprender mejor si una consulta es buena o mala