#SQL

Uso de Python en InterSystems Iris

Hola

🙂 Buenos días comunidad.

Me gustaría compartir con ustedes, en este artículo, una manera muy práctica, de obtener información relevante de todos los Namespaces de un Entorno. ¿Para qué?. Pues por ejemplo para uno de los casos de uso que más nos encontramos los desarrolladores con respecto a Healtshare: el desafío de necesitar crear 1 servicio, y la odisea de ir entorno a entorno, namespace a namespace, buscando si el puerto XYZAB está libre o no... 🙃

¡Hola a todos los estimados miembros de la comunidad de desarrolladores de InterSystems en español!

Aunque suelo consultar la comunidad de desarrolladores y alguna vez he dejado alguna pregunta por aquí, este será mi primer artículo y qué mejor ocasión para hacerlo que participando en el 3er concurso de artículos técnicos.

Si estáis migrando de Oracle a InterSystems IRIS, como muchos de mis clientes, podríais encontraros con patrones SQL específicos de Oracle que necesitan ser traducidos.

Tomad este ejemplo:

SELECT (TO_DATE('2023-05-12','YYYY-MM-DD') - LEVEL + 1) AS gap_date
FROM dual
CONNECT BY LEVEL <= (TO_DATE('2023-05-12','YYYY-MM-DD') - TO_DATE('2023-05-02','YYYY-MM-DD') + 1);

En Oracle:

En este tutorial, me gustaría hablar sobre las Consultas de Clase (Class Queries). Para ser más precisos, sobre las Consultas basadas en código escrito por el usuario:

Python se ha convertido en el lenguaje de programación más utilizado del mundo (fuente: https://www.tiobe.com/tiobe-index/) y SQL sigue siendo el líder como lenguaje para las bases de datos. ¿No sería genial que Python y SQL trabajaran juntos para ofrecer nuevas funcionalidades que SQL por sí mismo no puede? Después de todo, Python tiene más de 380.000 librerías publicadas (fuente: https://pypi.org/) con funciones muy interesantes para ampliar las consultas SQL dentro de Python.

En este artículo detallo cómo crear nuevos Procedimientos Almacenados de SQL en la base de datos de InterSystems IRIS usando Embedded Python.

¡Hola desarrolladores!

A veces, cuando desarrollamos una maqueta o una Prueba de Concepto (PoC), necesitamos una interfaz sencilla que proporcione datos en IRIS en JSON contra consultas SQL.

Y recientemente contribuí con un sencillo módulo que hace exactamente eso:

acepta una sentencia SQL y devuelve JSON.

¿Cómo se instala? Solo llama:

zpm "install sql-rest"

Si lo instalas en un namespace X, configurará un endpoint /sql en tu sistema, que aceptará solicitudes POST con una sentencia SQL y te devolverá el resultado para los datos disponibles en el namespace X.

He estado leyendo la guía de documentación para 2018.1 sobre los planes de consultas congeladas varias veces en los últimos días ( enlace ) y hay una respuesta que no encuentro directamente.

Mi forma de actualización on premise es:

Cuando trabajáis con InterSystems IRIS, los desarrolladores y arquitectos de bases de datos a menudo se enfrentan a una decisión crítica: si usar SQL Dinámico o SQL Embebido para consultar y actualizar datos. Ambos métodos tienen sus propias fortalezas y casos de uso, pero comprender sus implicaciones en el rendimiento es esencial para tomar la decisión correcta. El tiempo de respuesta, una métrica clave en la evaluación del rendimiento de las aplicaciones, puede variar significativamente dependiendo del enfoque de SQL que utilicéis. El SQL Dinámico ofrece flexibilidad, ya que las consultas pueden construirse y ejecutarse en tiempo de ejecución, lo que lo hace ideal para escenarios con necesidades de consulta impredecibles o altamente variables. Por el contrario, el SQL Embebido enfatiza la estabilidad y eficiencia al integrar el código SQL directamente en la lógica de la aplicación, ofreciendo tiempos de respuesta optimizados para patrones de consulta predefinidos.

En este artículo, exploraré los tiempos de respuesta al usar estos dos tipos de SQL y cómo dependen de las diferentes estructuras de clases y del uso de parámetros. Para ello, voy a utilizar las siguientes clases del diagrama:

Lo que encuentro realmente útil de IRIS al enseñar mi asignatura de bases de datos post-relacionales es el hecho de que es una base de datos multimodelo. Lo que significa que podéis abordar la arquitectura y la estructura una sola vez y, después, mostrar el uso de diferentes modelos (como el objeto, documento, jerárquico) utilizando el mismo lenguaje y enfoque. Y no es un gran salto pasar de un lenguaje de programación orientado a objetos (como C#, Java, etc.) a una base de datos orientada a objetos.

Sin embargo, junto con las ventajas (que son muchas), vienen algunos inconvenientes cuando pasamos del modelo orientado a objetos al relacional. Cuando digo que podéis acceder a los mismos datos utilizando diferentes modelos, también necesito explicar cómo es posible trabajar con listas y arrays del modelo objeto en una tabla relacional. Con los arrays es muy sencillo: por defecto se representan como tablas separadas y eso es todo. Con las listas es más complicado, porque por defecto son cadenas de texto. Pero uno sigue queriendo hacer algo con ellas sin dañar la estructura ni volver esta lista ilegible en el modelo objeto.

Así que en este artículo os mostraré un par de predicados y una función que son útiles al trabajar con listas, y no solo como campos.

Tengo una tabla con un campo TimeStamp. Necesito crearle un índice para mejorar la ejecución de consultas. Pero estoy dándole vueltas a cuál podría ser la mejor opción.

Variables de host son una característica de programación bastante común en muchas implementaciones de SQL.
Una pregunta reciente en DC me hizo darme cuenta de que en IRIS, Caché, Ensemble,...
las variables del host simplemente existen dentro del embedded SQL.

> You can supply host variables for Embedded SQL queries only. <
Se incluyen ejemplos relacionados en la documentación disponible.

A continuación se incluye una descripción de una solución alternativa si no utiliza o no puede utilizar embedded SQL.

He estado trabajando en este proceso con algunos compañeros de equipo y pensé que podría ser útil para otros, especialmente si trabajáis con HL7 y Ensemble/HealthConnect/HealthShare y rara vez os aventuráis más allá de la sección de Interoperabilidad.

En este artículo, nos adentraremos en el funcionamiento de una aplicación publicada en OpenExchange llamada db-management-tool que sirve como herramienta de gestión de bases de datos, explorando la arquitectura y las tecnologías que la sustentan. Comprenderemos cómo funciona la aplicación para daros una visión de su diseño, cómo gestiona bases de datos, tablas y cómo la API interactúa con los datos.