Find

Article
· 9 hr ago 4m read

Namespaces e bancos de dados: fundamentos do funcionamento interno do InterSystems IRIS

O InterSystems IRIS é construído sobre uma arquitetura que separa a organização lógica dos dados (namespaces) de seu local de armazenamento físico (bancos de dados). Compreender essa separação e a distinção entre Namespaces e Bancos de Dados é crucial para uma gestão de dados eficaz, segurança e, especialmente, para o compartilhamento de dados de alta performance.

Neste artigo, discutirei esses componentes fundamentais e fornecerei um guia prático sobre como aproveitar os mapeamentos de globals para compartilhar estruturas de dados nativas (globals) entre diferentes ambientes lógicos.

Bancos de Dados: A Realidade Física

Um banco de dados representa a realidade física de onde os dados estão armazenados no disco. Antes de tudo, é um arquivo em um sistema de arquivos chamado IRIS.dat (por exemplo, <Pasta de instalação>\mgr\user\IRIS.DAT). O tamanho máximo deste arquivo é de 32TB. Ele é o contêiner para todos os dados reais e o código. Os bancos de dados são gerenciados pelo kernel do IRIS, que lida com cache, journaling e registro de transações no nível do arquivo físico.

Quando você instala o DBMS InterSystems IRIS, os seguintes bancos de dados são instalados automaticamente:

Quando você está trabalhando em um ambiente de produção, é fortemente recomendado que você crie um banco de dados dedicado separado ou vários para armazenar seus dados e código.

Para criar um novo banco de dados, vá em System > Configuration > Local Databases > Create New Database e forneça um nome e um diretório onde ele deve ser armazenado:

Namespaces: Sandbox Lógica

Um namespace no InterSystems IRIS representa um ambiente de trabalho lógico e autocontido. Ele é análogo a um schema em um banco de dados relacional ou a um workspace de projeto. Ele define o escopo de todos os elementos da aplicação: classes persistentes (objetos), rotinas (código) e, mais importante, globals (estruturas de dados nativas). Além disso, as aplicações que rodam em um namespace são logicamente isoladas daquelas em outro. Isso evita conflitos entre diferentes aplicações ou ambientes de desenvolvimento (ex: Desenvolvimento, Staging, Produção). Do ponto de vista do desenvolvedor, tudo — dados e código — reside dentro dos limites do namespace ao qual ele está conectado. Cada processo de aplicação IRIS roda em um namespace. Se você deseja acessar dados/código em outro namespace, precisa alterá-lo explicitamente.

Quando você instala o DBMS InterSystems IRIS, os seguintes namespaces são configurados automaticamente:

  • %SYS
  • USER

Mapeando a Lógica para a Física

O link entre um Namespace e um Banco de Dados é estabelecido através de um Mapeamento. Cada Namespace possui um conjunto definido de mapeamentos que especificam qual banco de dados físico (ou bancos) deve ser usado para armazenar seus elementos.

Por exemplo, temos vários bancos de dados:

  • Clients – contém dados sobre clientes
  • Finances – contém dados financeiros que permitem trabalhar tanto com clientes quanto com fornecedores
  • Vendors – contém dados sobre fornecedores

e dois namespaces:

  • Billing – possui mapeamento para clients e parte ou todas as informações de finances, permitindo que as aplicações que trabalham com este namespace obtenham todas as informações necessárias para lidar com clientes
  • Purchasing – possui mapeamento para vendors e parte ou todas as informações de finances, permitindo que as aplicações que trabalham com este namespace obtenham todas as informações necessárias para lidar com fornecedores

Ao mesmo tempo, cada namespace possui um banco de dados padrão para dados e código.

Neste exemplo, poderia ser:

Você define qual banco de dados deve ser o padrão para o namespace quando você cria um namespace (System > Configuration > Namespaces > New Namespace):

O banco de dados para armazenamento temporário será o IRISTEMP por padrão.

O banco de dados para Globals armazena dados, enquanto o banco de dados para Routines armazena código e descrições de classes.

Se você deseja adicionar mais mapeamentos de dados para outros bancos de dados, vá em System > Configuration > Namespaces > (Escolha o namespace) > Global Mappings > New e adicione um novo mapeamento:

Como você pode ver, é possível configurar o acesso em detalhes minuciosos – incluindo os subscripts (subscritos) de globals específicas.

O mesmo pode ser feito para mapeamentos de Rotinas (Routine mappings).

Além dos mapeamentos definidos pelo usuário, também existem mapeamentos de sistema. Códigos e dados de nível de sistema (como definições de classes de sistema, rotinas e globals específicas de sistema começando com ^%) são mapeados para bancos de dados de sistema (ex: IRISLIB, IRISSYS). Isso garante que os dados da aplicação não interfiram nos componentes principais do sistema.


Ao separar o Namespace lógico do Banco de Dados físico, e ao utilizar mapeamentos, você ganha controle refinado sobre a localização dos dados, segurança e performance.

Discussion (0)1
Log in or sign up to continue
Digest
· 9 hr ago

InterSystems Developers Publications, Week January 12 - 18, 2026, Digest

Articles
#InterSystems IRIS
#InterSystems IRIS for Health
#Open Exchange
Announcements
#InterSystems IRIS
#Global Masters
#Developer Community Official
#TrakCare
#Summit
#HealthShare
#Other
Questions
January 12 - 18, 2026Week at a GlanceInterSystems Developer Community
Digest
· 10 hr ago

Nuevas publicaciones en la Comunidad de InterSystems, 12-18 enero

Artículos
#InterSystems IRIS
#Open Exchange
Reseñas en Open Exchange - #61
Por Jose-Tomas Salvador
#InterSystems IRIS for Health
Anuncios
12-18 eneroWeek at a GlanceInterSystems Developer Community
Digest
· 12 hr ago

Publications des développeurs d'InterSystems, semaine Janvier 12 - 18, 2026, Résumé

Janvier 12 - 18, 2026Week at a GlanceInterSystems Developer Community
Announcement
· 12 hr ago

Notas de la versión 0.10.5 de IPM

IPM versión 0.10.5 se ha lanzado el 15 de enero de 2026. Esta nueva versión incluye un montón de mejoras y correcciones de errores, así que aseguraos de echarle un vistazo, ya sea directamente desde la página de GitHub o desde el Registro de la Comunidad.

Los cambios más importantes incluyen lo siguiente:

  • Una reescritura de la resolución de dependencias que mejora drásticamente el rendimiento, incluyendo un aumento de velocidad de 200 veces en casos muy complicados.
  • Un registro de historial que realiza el seguimiento de las instalaciones, cargas, actualizaciones y desinstalaciones de IPM, que podéis consultar usando zpm "log" 
  • Las expresiones del sistema, como ${namespace}, y las macros $$$ ahora se evalúan en los archivos de combinación CPF, lo que permite una mayor flexibilidad en la configuración inicial.
  • <Invoke> en module.xml se comporta de forma más intuitiva al comprobar siempre el valor de retorno %Status si y solo si la firma del método declara que se devuelve %Status. Esto significa que se lanzará un error si no se devuelve nada, si el valor devuelto no es un %Status o si no es $$$OK.

Aquí tenéis la lista completa de cambios:

Añadidos

  • #938: Añadida la opción -export-python-deps al comando package
  • #462: El comando repo para la configuración de repositorios ahora admite el modo de entrada secreta por terminal para contraseñas con la opción -password-stdin
  • #935: Se añade un procesador genérico de recursos tarball de JFrog Artifactory para empaquetar artefactos con un paquete y desplegarlos en una ubicación final durante la instalación
  • #950: Añadido soporte para listar paquetes de Python instalados usando list -pythonlist -py and list-installed -python
  • #822: El procesador de recursos CPF ahora admite expresiones del sistema y macros en archivos de combinación CPF
  • #578: Añadida funcionalidad para registrar y mostrar el historial de IPM de instalación, desinstalación, carga y actualización
  • #961: Se añade la creación de un archivo de bloqueo para un módulo usando la opción -create-lockfile durante la instalación
  • #959: En repositorios ORAS, el nombre externo ahora puede usarse indistintamente con el nombre (predeterminado) para instally update; es decir, un módulo publicado con su nombre (predeterminado) puede instalarse usando su nombre externo
  • #951: El comando unpublishomitirá la solicitud de confirmación al usuario si se proporciona la opción-force
  • #1018: Se requiere el nombre del módulo para desinstalar cuando no se utiliza la opción -all

Cambiados

  • #316: Todos los parámetros, excepto el modo desarrollador, incluidos en un comando loadinstall o update se propagarán a las dependencias
  • #885: Cargar siempre las dependencias de forma síncrona y permitir que cada módulo gestione el multihilo según sea necesario para la carga usando multicompile, en lugar de intentar gestionar el multihilo propio de la carga de elementos, lo que provoca contención de bloqueos al evitar el compilador de IRIS
  • #481: Mejora del rendimiento de BuildDependencyGraph realizando lo siguiente:
    • Eliminar la recursión y usar iteración.
    • Eliminar la búsqueda en profundidad y usar únicamente búsqueda en anchura.
    • Mejorar el almacenamiento en caché de los resultados de búsqueda de módulos colapsando las expresiones de búsqueda (reduciendo expresiones que son intersecciones).

Eliminados

  • #938: Eliminada la gestión de la opción secreta NewVersion en %Publish()

Corregidos

  • #943: El comando load, cuando se usa con una URL de repositorio de GitHub, vuelve a aceptar un argumento branch
  • #701: Corregidos comentarios de ayuda engañosos sobre el comando search
  • #958: El comando update ya no falla de forma prematura si se utiliza el nombre externo
  • #970: Corregido error en el procesamiento del comando 'generate' de WebApp
  • #965: FileCopy en un directorio con un Name sin la barra inicial ahora funciona
  • #937: Publicar un módulo con un <WebApplication> que contiene un Path ya no provoca errores
  • #957: Mejorados los mensajes de error para la ejecución de comandos del SO. Ahora, cuando un comando falla, el mensaje de error incluye el comando completo y su código de retorno. También se corrigió la separación de argumentos para el comando attrib de Windows y se eliminó el manejo de errores engañoso para comandos ausentes
  • #789: Corregido error al listar módulos para un repositorio ORAS con un namespace especificado
  • #999, #1000: La instalación de IPM ahora limpia las asignaciones obsoletas usadas en versiones anteriores de IPM
  • #1007: La expresión ${ipmDir}ahora funciona en el <Arg>de un <Invoke>
  • #1015: Corregidos errores en la resolución de dependencias donde * como requisito de versión y rangos que se intersectan no funcionaban correctamente
  • #1036: El comando update ya no propaga el modo desarrollador a las dependencias

Obsoletos

  • #828: La opción CheckStatus para la acción <Invoke>ha quedado obsoleta. El comportamiento predeterminado ahora es comprobar siempre el estado del método si y solo si la firma del método devuelve %Library.Status
  • #885: La opción -synchronous ha quedado obsoleta, ya que cargar las dependencias de forma síncrona ahora es el comportamiento predeterminado

Seguridad

  • Se ha actualizado el paquete urllib3 wheel a la versión 2.6.3

Si tenéis alguna pregunta, sugerencia o error que queráis reportar, no dudéis en comentarlo aquí o en la página de GitHub. (En GitHub, las preguntas y sugerencias deben ir a la página de discusiones, y los errores a la página de issues.)

Discussion (0)1
Log in or sign up to continue