#SQL

En SQL, la condición más frecuente WHERE se relaciona principalmente con el contenido de las filas en las que trabajas.
Por lo tanto, debe calcularse y verificarse para cada fila a la que accedas.
Distinto es el caso (y por eso la llamé ESTÁTICA) de una condición WHERE independiente de las filas a las que accedes.

Ejemplos de Mapeos

Obviamente, si tienes un cuatro artículo en la trilogía, debes apostar por las ganancias económicas y escribir el quinto, ¡así que aquí está!

Nota: Hace muchos años, Dan Shusman me dijo que el mapeo de globals es una forma de arte. No existe una manera correcta o incorrecta de hacerlo. El modo en que interpretes los datos te llevará al tipo de mapeo que realizas. Como siempre, existe más de una forma de llegar a la respuesta final. Según vayas revisando mis ejemplos, verás que hay algunos en los que se mapean el mismo tipo de datos, pero de distintas maneras.

Esta publicación es el resultado directo de trabajar con un cliente de InterSystems que acudió a mí con el siguiente problema:

SELECT COUNT(*) FROM MyCustomTable

Esto tarda 0.005 segundos, con 2300 filas en total. Sin embargo:

¡Hola Desarroladores!

IRIS External Table es un proyecto de código abierto de la comunidad de InterSystems, que permite utilizar archivos almacenados en el sistema de archivos local y almacenar objetos en la nube como AWS S3 y tablas SQL.

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.

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      
¡NO está soportado por el servicio de soporte de InterSystems!   

Los globals en Caché, Ensemble e IRIS normalmente son invisibles a través de SQL.
En este ejemplo se muestra cómo verlos desde SQL.

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”).*

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.

Preguntas frecuentes de InterSystems

Se pueden recuperar estos datos utilizando el esquema INFORMATION_SCHEMA.

INFORMATION_SCHEMA es un esquema de sistema y no se muestra por defecto en el menú SQL del Portal de Gestión.

El método para mostrarlo es el siguiente:

Hay una nueva funcionalidad muy interesante en la recientemente anunciada versión de prueba 2024.1 de InterSystems IRIS - JSON_TABLE. JSON_TABLE forma parte de una familia de funciones introducidas en la versión 2016 del estándar SQL (ISO Standard, publicado a principios de 2017). Permite que valores JSON se mapeen a columnas y se consulten usando SQL. JSON_TABLE puede usarse en la cláusula FROM de algunas sentencias SQL.

La sintaxis de JSON_TABLE es bastante extensa, permitiendo condiciones excepcionales cuando los valores JSON proporcionados no cumplen las expectativas, estructuras anidadas, etc.

La sintaxis básica es bastante sencilla. El primer argumento pasado a JSON_TABLE es el valor JSON que se va a consultar. Puede ser un literal, una referencia a una columna o una llamada a una función. El segundo argumento es una expresión JPL (JSON Path Language), que permite filtrar el valor proporcionado. Después va la cláusula COLUMNS - justo en medio de la llamada a la función. La cláusula COLUMNS se parece mucho a las definiciones de columnas en una sentencia CREATE TABLE pero con un añadido muy necesario - el PATH. PATH es una expresión JPL que se aplica al valor JSON para producir el valor de la columna.

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:

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!

En mis artículos anteriores, una de las cosas más interesantes de FHIR que mencioné es el amplio rango de posibilidades que tenemos y no solo para crear algo, sino las maneras de conseguir este objetivo.

En mis artículos estoy compartiendo mi experiencia trabajando con FHIR. Solo usaba los Recursos FHIR aportados por la API. Recuperando y actualizando los Recursos FHIR en el servidor FHIR usando javascript con la ayuda de fhir.js

Recientemente surgió un patrón interesante en torno a los índices únicos (en una discusión interna re: isc.rest) y me gustaría destacarlo para la Comunidad.

Como caso de uso motivador: supón que tienes una clase que representa un árbol, donde cada nodo también tiene un nombre, y queremos que los nodos sean únicos por nombre y nodo principal. Queremos que cada nodo raíz también tenga un nombre único. Una implementación natural sería: