Como você sabe, o IRIS da InterSystems além de globais, objetos, documentos e modelos de dados XML também suporta relacional onde o SQL é esperado como uma linguagem para lidar com os dados.
E como em outros DBMS relacionais, o InterSystems IRIS possui seu próprio dialeto.
Começo esta postagem para dar suporte a uma folha de dicas SQL e convido você a compartilhar seus favoritos - atualizarei o conteúdo com os comentários recebidos.
Isso pode ser conseguido usando o procedimento CSV() da classe %SQL.Util.Procedures . Abaixo está o exemplo de uso do código. (Assumindo que o arquivo test.csv está em c:\temp.)
Como você deve se lembrar do Global Summit 2022 ou do 2022.2 launch webinar, estamos lançando um novo e empolgante recurso para incluir em suas soluções analíticas no InterSystems IRIS. O Armazenamento Colunar apresenta uma maneira alternativa de armazenar os dados da tabela SQL que oferece uma aceleração de ordem de grandeza para consultas analíticas. Lançado pela primeira vez como um recurso experimental em 2022.2, o mais recente Developer Preview 2022.3 inclui várias atualizações que achamos que valeriam uma postagem rápida aqui.
Eu criei uma classe que gera código para query customizada a partir de uma global qualquer em um determinado namespace, fazendo com que a global responda ao padrão SQL imediatamente.
Há três coisas mais importantes para qualquer converrsa sobre performance SQL: Índices, TuneTable e Plano de Consulta. Os PDFs anexos incluem apresentações históricas sobre esses tópicos que cobrem os fundamentos desses 3 itens em um só lugar. Nossa documentação fornece mais detalhes sobre esses e outros tópicos de desempenho do SQL nos links abaixo. As opções de eLearning reforçam vários desses tópicos. Além disso, há vários artigos da Comunidade de Desenvolvedores que abordam o desempenho do SQL, e os links relevantes também estão listados.
Há uma quantidade considerável de repetição nas informações listadas abaixo. Os aspectos mais importantes do desempenho do SQL a serem considerados são:
Os tipos de índices disponíveis
O uso de um tipo de índice em vez de outro
As informações que o TuneTable coleta para uma tabela e o que isso significa para o Otimizador
Como ler um Plano de Execução para melhor entender se uma consulta é boa ou ruim
De acordo com o relatório OWASP Top Ten de 2021, um documento de referência na área de segurança de aplicações web, as injeções SQL ocupam a terceira posição entre os riscos mais críticos. Este relatório, disponível em OWASP Top 10: Injection, destaca a gravidade dessa ameaça e a necessidade de implementar medidas de proteção eficazes.
Uma injeção SQL ocorre quando um atacante malicioso consegue inserir código SQL não autorizado em uma consulta enviada a um banco de dados. Esse código, disfarçado nas entradas do usuário, pode então ser executado pelo banco de dados, causando ações indesejáveis como o roubo de dados confidenciais, a modificação ou a exclusão de informações sensíveis, ou ainda a interrupção do funcionamento da aplicação.
Em ObjectScript, você tem uma ampla coleção de funções que retornam algum valor tipicamente:
set variable = $somefunction(param1,param2, ...)
Não há nada de especial nisso. Mas há um conjunto de funções que classifico como Funções de Lado Esquerdo A especialidade delas é que você também pode usá-las à esquerda do operador igual como um alvo no comando SET:
Se você encontrou o problema de que nem todas as linhas do seu resultado estão retornando no seu snapshot, você está no lugar certo.
Ao usar snapshots, existe uma informação não trivial de que eles têm um máximo de linhas que vem por padrão como 250.
Para mudar isso é muito simples. Ao invés de enviar o snapshot como referência direto no seu método de execução de query ou procedure, vamos inicializá-lo antes e definir um valor na propriedade MaxRowsToGet.
Não tenho certeza se muitos se conectam ao MS SQL para executar consultas, procedimentos armazenados, etc., mas nosso Sistema de Saúde possui muitos bancos de dados baseados em MS SQL que utilizamos no ambiente de Interoperabilidade por vários motivos.
Com a migração do ambiente local para a nuvem, enfrentamos algumas dificuldades com as conexões do SQL Gateway e como configurá-las para usar o Microsoft Entra para autenticação do Active Directory.
Introdução: Quando o IRISTEMP Armazena Dados Demais
Então, você verificou seu servidor e viu que o IRISTEMP está crescendo demais. Não precisa entrar em pânico. Vamos investigar o problema antes que seu armazenamento acabe.
Passo 1: Confirmar o Problema de Crescimento do IRISTEMP
Antes de assumir que o IRISTEMP é o problema, vamos verificar seu tamanho real.
Migrar de Oracle, MSSQL ou outros sistemas de banco de dados puramente relacionais para um InterSystems IRIS multimodel é uma decisão estratégica que requer planejamento e execução cuidadosos. Embora essa transição ofereça benefícios significativos, incluindo desempenho aprimorado, escalabilidade e suporte para arquiteturas modernas, ela também apresenta desafios. Neste artigo, destacarei algumas das considerações relacionadas à codificação para garantir uma migração bem-sucedida. Deixarei tudo o que está conectado a uma migração real de estruturas e dados fora do escopo deste artigo.
Primeiramente, ao considerar migrar para um sistema de banco de dados diferente, você precisa entender sua lógica de negócios, seja ela do lado da aplicação (servidor de aplicação) ou do servidor de banco de dados. Basicamente, onde você tem suas instruções SQL que potencialmente precisará reescrever?
Ao trabalhar com InterSystems IRIS, desenvolvedores e arquitetos de banco de dados frequentemente enfrentam uma decisão crítica: usar Dynamic SQL ou Embedded SQL para consultar e atualizar dados. Ambos os métodos têm seus pontos fortes e casos de uso únicos, mas entender suas implicações de desempenho é essencial para fazer a escolha certa. O tempo de resposta, uma métrica chave na avaliação do desempenho de aplicações, pode variar significativamente dependendo da abordagem SQL utilizada. Dynamic SQL oferece flexibilidade, pois as consultas podem ser construídas e executadas em tempo de execução, tornando-o ideal para cenários com necessidades de consulta imprevisíveis ou altamente variáveis. Por outro lado, Embedded SQL enfatiza a estabilidade e a eficiência ao integrar código SQL diretamente na lógica da aplicação, oferecendo tempos de resposta otimizados para padrões de consulta predefinidos.
Neste artigo, explorarei os tempos de resposta ao usar esses dois tipos de SQL e como eles dependem de diferentes estruturas de classe e do uso de parâmetros. Para fazer isso, usarei as seguintes classes do diagrama:
Se você está migrando do Oracle para o InterSystems IRIS — como muitos dos meus clientes — pode se deparar com padrões específicos de SQL do Oracle que precisam ser adaptados.
Veja esse examplo:
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);
Por visualizações
Open Exchange app.png)
.png)
.png)
Primeiramente, ao considerar migrar para um sistema de banco de dados diferente, você precisa entender sua lógica de negócios, seja ela do lado da aplicação (servidor de aplicação) ou do servidor de banco de dados. Basicamente, onde você tem suas instruções SQL que potencialmente precisará reescrever?.png)