🏆
Projetos da Comunidade
Giovanni Vasconcelos
Giovanni Vasconcelos
 · Gio

Guia Completo de Melhores Práticas para Consultas SQL no ERP Sankhya (SQL Server)

Este documento foi elaborado para orientar desenvolvedores e analistas na criação de consultas SQL bem estruturadas, legíveis e otimizadas para o ambiente do ERP Sankhya, utilizando SQL Server. Abordaremos desde a formatação do código até técnicas de otimização e dicas específicas para ferramentas como o DB Explorer e o construtor de dashboards.

1. Introdução

No desenvolvimento de consultas SQL em ambientes corporativos, como o ERP Sankhya, a clareza e a eficiência são fundamentais. Uma query bem escrita não só melhora a manutenção e o entendimento por parte de outros profissionais, mas também pode impactar positivamente a performance dos dashboards e relatórios que dependem desses dados.

No Sankhya, o uso do SQL Server é comum e o ambiente impõe alguns desafios e limitações, como o limite de linhas no DB Explorer e restrições no construtor de dashboards. Assim, é essencial seguir boas práticas de codificação e formatação para garantir que as consultas sejam robustas e performáticas.

2. Indentação e Organização do Código SQL

2.1. Importância da Boa Formatação

A formatação do código é uma parte essencial da escrita de consultas SQL. Um código bem indentado e organizado:

  • Facilita a leitura e a compreensão: Quando o código está estruturado, fica mais fácil identificar cada parte da consulta (cláusulas, condições, junções, subconsultas).

  • Auxilia na manutenção: Ao revisitar ou alterar uma query, a formatação adequada reduz a chance de erros e acelera a identificação de partes críticas.

  • Aumenta a colaboração: Em ambientes corporativos, várias pessoas podem trabalhar na mesma base de consultas. Um padrão claro ajuda toda a equipe a compreender e modificar o código conforme necessário.

2.2. Princípios de Indentação e Organização

Quebra de Linhas por Cláusula

  • Cada cláusula em linha separada: Inicie cada comando principal em uma nova linha. Por exemplo:

    • SELECT

    • FROM

    • JOIN

    • WHERE

    • GROUP BY

    • HAVING

    • ORDER BY

Isso permite que cada etapa da consulta seja facilmente identificada.

Indentação de Elementos Internos

  • Colunas no SELECT: Liste cada coluna em uma nova linha, com um recuo (4 espaços ou um tab), para diferenciar os campos.

  • Condições no WHERE e JOIN: Indente as condições para separar visualmente as diferentes partes de uma cláusula.

  • Subconsultas e CTEs: Se a consulta incluir subconsultas ou expressões com WITH, indente o conteúdo dentro dos parênteses para diferenciar do restante da query.

Espaçamento e Separadores

  • Uso de espaços em branco: Insira espaços ao redor dos operadores (ex.: =, <, >) e após vírgulas para melhorar a legibilidade.

  • Linhas em branco para separar blocos lógicos: Em consultas muito longas, insira uma linha em branco para separar blocos lógicos (ex.: entre os JOINs e o WHERE).

Exemplos Práticos

Exemplo sem formatação adequada (a ser evitado):

sql

SELECT CAB.CODPARC, PAR.RAZAOSOCIAL, BAI.NOMEBAI FROM TGFCAB CAB JOIN TGFPAR PAR ON CAB.CODPARC=PAR.CODPARC JOIN TSICID CID ON CID.CODCID=PAR.CODCID WHERE CID.CODCID=973 AND CAB.STATUSNOTA='L' AND CAB.TIPMOV='V';

Exemplo com boa formatação:

sql

SELECT 
    CAB.CODPARC      AS "CÓDIGO",
    PAR.RAZAOSOCIAL  AS "RAZÃO SOCIAL",
    BAI.NOMEBAI      AS "BAIRRO"
FROM TGFCAB CAB
JOIN TGFPAR PAR 
    ON CAB.CODPARC = PAR.CODPARC
JOIN TSICID CID 
    ON CID.CODCID = PAR.CODCID
JOIN TSIBAI BAI 
    ON PAR.CODBAI = BAI.CODBAI
WHERE CID.CODCID     = 973 
  AND CAB.STATUSNOTA = 'L' 
  AND CAB.TIPMOV     = 'V';

Note como cada parte da query é apresentada de forma clara, facilitando a identificação dos diferentes componentes.

3. Uso de CTEs vs. Subqueries

3.1. Definições e Diferenças

  • Subquery (Subconsulta):
    Uma subquery é uma consulta aninhada dentro de outra consulta. Pode aparecer em cláusulas como SELECT, FROM ou WHERE.
    Exemplo de subquery em SELECT:

sql

SELECT Nome,
       (SELECT SUM(Valor)
        FROM Vendas
        WHERE ClienteId = c.Id
        AND YEAR(DataVenda) = 2024) AS TotalVendas2024
FROM Clientes c;

  • CTE (Common Table Expression):
    Uma CTE é definida antes da consulta principal usando a cláusula WITH. Permite nomear e reutilizar um conjunto de resultados em diferentes partes da query. Exemplo de CTE:

sql

WITH Vendas2024 AS (
    SELECT ClienteId, SUM(Valor) AS TotalValor
    FROM Vendas
    WHERE YEAR(DataVenda) = 2024
    GROUP BY ClienteId
)
SELECT c.Nome, COALESCE(v.TotalValor, 0) AS TotalVendas2024
FROM Clientes c
LEFT JOIN Vendas2024 v 
  ON c.Id = v.ClienteId;

3.2. Vantagens das CTEs

  • Melhor legibilidade:
    A CTE permite separar a lógica de obtenção dos dados intermediários da consulta principal. Ao nomear a CTE com um nome significativo (ex.: Vendas2024), fica claro qual é o propósito daquela parte da consulta.

  • Reutilização de Lógica:
    Se o mesmo conjunto de dados é usado em mais de um lugar na consulta, a CTE evita a duplicação de código. Você define a lógica uma única vez e a referencia quantas vezes for necessário.

  • Facilidade na criação de consultas recursivas:
    Em casos onde há hierarquias (como estruturas de árvore, listas de materiais, etc.), as CTEs recursivas são extremamente úteis e não há equivalente direto com subqueries convencionais.

3.3. Quando Utilizar Cada Abordagem

  • Subqueries:
    São indicadas para operações simples e isoladas, quando a lógica não é complexa e não precisa ser reutilizada.
    Exemplo: Uma subconsulta no WHERE para verificar a existência de um registro.

  • CTEs:
    Preferíveis em consultas complexas, onde há múltiplas camadas de lógica, agregações ou junções. Além disso, quando a mesma lógica precisa ser referenciada mais de uma vez, a CTE é a escolha ideal.

3.4. Impacto na Performance

Em geral, o otimizador do SQL Server transforma as CTEs em subqueries ou em views temporárias no momento da execução, sem prejuízo direto à performance. Contudo, a clareza proporcionada pelas CTEs pode facilitar a identificação de gargalos e a aplicação de ajustes quando necessário.

4. Convenções de Nomenclatura

Manter um padrão consistente na nomenclatura dos objetos SQL é crucial para a manutenção e a legibilidade do código. As práticas abaixo são recomendadas:

4.1. Palavras-Chave

  • Maiúsculas para comandos SQL:
    Escreva os comandos SQL (como SELECT, FROM, JOIN, WHERE, GROUP BY) sempre em caixa alta. Isso ajuda a diferenciá-los dos nomes de tabelas, colunas e alias, que podem seguir outro padrão.
    Exemplo:

sql

SELECT Nome, Sobrenome FROM Clientes WHERE Ativo = 1;

4.2. Nomes de Tabelas e Colunas

  • Adotar o padrão Sankhya:
    No ERP Sankhya, os nomes de tabelas e colunas geralmente aparecem em maiúsculas (ex.: TGFPAR, CODPARC).

  • Consistência:
    Siga o padrão já estabelecido pelo sistema para evitar confusões. Se a base de dados utiliza maiúsculas, mantenha essa convenção em todas as suas queries.

4.3. Uso de Aliases

  • Aliases de tabelas:
    Utilize aliases curtos e significativos para as tabelas, facilitando referências posteriores. Por exemplo, TGFPAR pode ser referenciada como PAR, e TGFCAB como CAB.

  • Prefixo em colunas:
    Sempre prefixe o nome da coluna com o alias da tabela, mesmo que não haja ambiguidade. Isso evita erros, especialmente em consultas com múltiplas tabelas.Exemplo:

sql

SELECT PAR.CODPARC, PAR.RAZAOSOCIAL
FROM TGFPAR PAR;

  • Aliases de colunas (rótulos):
    Quando necessário, utilize a cláusula AS para renomear as colunas no resultado, principalmente se os dados serão exibidos em um relatório ou dashboard. Caso o alias contenha espaços ou caracteres especiais, coloque-o entre aspas duplas.Exemplo:

sql

SELECT PAR.CODPARC AS "Código do Parceiro",
       PAR.RAZAOSOCIAL AS "Razão Social"
FROM TGFPAR PAR;

4.4. Boas Práticas Gerais

  • Evite nomes genéricos:
    Utilize nomes que descrevam claramente o conteúdo ou o propósito da tabela/coluna. Por exemplo, evite TBL1 ou col1; prefira nomes como CLIENTES ou DATA_VENDA.

  • Nomes sem ambiguidades:
    Se uma mesma coluna existe em tabelas diferentes (como ID, DATA ou STATUS), sempre prefira referenciar com o alias da tabela.

  • Padronize a escrita:
    Se optar por usar maiúsculas para nomes de tabelas e colunas, mantenha esse padrão em toda a consulta. A consistência é essencial para a manutenção.

5. Otimização de Performance e Legibilidade

Escrever consultas eficientes não significa apenas que elas rodem mais rápido, mas também que sejam fáceis de entender e manter. A seguir, são apresentadas práticas e dicas para otimizar a performance e a clareza das queries.

5.1. Seleção de Colunas

  • Evite SELECT *:
    Sempre especifique as colunas necessárias. Selecionar todas as colunas pode trazer dados irrelevantes e aumentar o tempo de resposta.
    Exemplo:

sql

-- Evite:
SELECT * FROM TGFPAR;

-- Prefira:
SELECT CODPARC, RAZAOSOCIAL FROM TGFPAR;

5.2. Filtros e Cláusula WHERE

  • Filtre os dados o quanto antes:
    Utilize o WHERE para restringir o conjunto de dados a ser processado. Isso é particularmente importante em tabelas grandes.

  • Uso correto de condições:
    Utilize parênteses para agrupar condições, evitando ambiguidades.
    Exemplo:

sql

WHERE (Status = 'A' OR Status = 'B')
  AND Data >= '2024-01-01'

  • Cuidado com funções em filtros:
    Evite aplicar funções em colunas indexadas (ex.: WHERE YEAR(DataVenda) = 2024) pois isso pode impedir o uso do índice. Prefira:

sql

WHERE DataVenda >= '2024-01-01'
  AND DataVenda < '2025-01-01'

5.3. Junções (JOINs)

  • Utilize a sintaxe ANSI JOIN:
    Separe claramente as condições de junção e os filtros.
    Exemplo:

sql

FROM TGFCAB CAB
JOIN TGFPAR PAR 
    ON CAB.CODPARC = PAR.CODPARC

  • Cuidados com LEFT JOIN e filtros:
    Se utilizar um LEFT JOIN, evite colocar condições referentes à tabela do lado direito diretamente no WHERE, a menos que queira filtrar os registros nulos. Se for necessário, coloque a condição no próprio ON.

  • Verifique duplicações:
    Em junções 1-para-N, certifique-se de não multiplicar registros que possam afetar cálculos de agregação. Em casos de soma ou média, considere agregar os dados antes de fazer o JOIN.

5.4. Agregações e GROUP BY

  • Clareza no GROUP BY:
    Ao usar funções de agregação, liste no GROUP BY todas as colunas que não estão envolvidas na função.

  • Uso do HAVING:
    Utilize HAVING para filtrar os resultados após a agregação, deixando o WHERE para filtros individuais.

  • Alias para agregados:
    Dê nomes significativos aos campos agregados para facilitar a compreensão dos resultados.Exemplo:

sql

SELECT ClienteId, SUM(Valor) AS TotalVendas
FROM Vendas
WHERE DataVenda BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY ClienteId
HAVING SUM(Valor) > 1000;

5.5. Funções ANSI e Portabilidade

  • Prefira COALESCE:
    Em vez de usar funções específicas como ISNULL (SQL Server) ou NVL (Oracle), use COALESCE para manter a portabilidade do código:

sql

SELECT COALESCE(Valor, 0) AS ValorCorrigido
FROM TabelaExemplo;

5.6. Boas Práticas Adicionais

  • Evite a complexidade excessiva:
    Mantenha suas queries simples. Se uma consulta ficar muito complexa, considere dividi-la em partes usando CTEs ou views.

  • Teste e valide:
    Utilize o DB Explorer e ferramentas como o SQL Server Management Studio (SSMS) para testar e medir a performance da sua consulta. Verifique os planos de execução para identificar gargalos.

  • Documentação interna:
    Adicione comentários explicando partes complexas ou lógicas específicas da query. Esses comentários auxiliam futuras manutenções e revisões.

6. Dicas Específicas para o ERP Sankhya

6.1. DB Explorer

O DB Explorer do Sankhya é uma ferramenta muito útil para a execução e o teste rápido de consultas SQL. No entanto, ele possui algumas particularidades:

  • Limite de Exibição:
    O DB Explorer possui um limite de exibição de 5.000 linhas. Portanto, se sua query retornar mais registros, você visualizará apenas os primeiros 5.000.
    Dica: Utilize filtros adequados para restringir o volume de dados e garanta que a consulta seja representativa.

  • Acesso Controlado:
    Geralmente, o DB Explorer é acessível apenas a usuários com perfil SUP (superusuário) ou com permissões específicas.
    Atenção: Não utilize essa ferramenta para operações de escrita ou para executar comandos DML (UPDATE, DELETE) que possam comprometer a integridade dos dados.

  • Uso para Desenvolvimento:
    Utilize o DB Explorer para iterar e validar a lógica de suas queries antes de implementá-las em dashboards. É uma ótima forma de testar subconsultas, CTEs e joins de maneira interativa.

6.2. Construtor de Dashboards (Componentes de BI)

O construtor de dashboards no Sankhya permite que você integre consultas SQL diretamente nos componentes visuais dos seus relatórios e painéis. Algumas recomendações específicas:

Modo Avançado de Edição

  • SQL Manual:
    Ao optar por escrever a consulta manualmente na aba Avançado, você desativa o assistente visual. Certifique-se de que a query esteja bem estruturada, pois não haverá correção automática.

  • Exibição Limitada:
    A aba de resultados do construtor de dashboards exibe somente 20 linhas como amostra. Esse é apenas um preview; a execução real da consulta no dashboard pode retornar um conjunto completo de dados.

  • Parâmetros Dinâmicos:
    O Sankhya permite o uso de placeholders para parâmetros. Existem duas sintaxes comuns:

    • :@PARAM – Pode exigir a inclusão manual de aspas para strings.

    • :#PARAM – Preferido por tratar automaticamente os tipos e aspas.
      Exemplo:

sql

SELECT *
FROM TSIUSU
WHERE CODEMP = :#CODEMP
  AND NIVEL  = :#NIVEL;

Ao usar :#PARAM, o sistema realiza a substituição do valor de forma automática, reduzindo erros de formatação e melhorando a segurança contra SQL injection.

Performance e Frequência de Execução

  • Consulta Otimizada:
    Dashboards podem ser acessados com frequência, e cada acesso executa a consulta. Garanta que a query seja otimizada para não sobrecarregar o servidor.

  • Pré-agregação de Dados:
    Se uma consulta é muito pesada, considere a criação de views ou tabelas auxiliares que pré-agreguem os dados, e então utilize essas estruturas no dashboard.

  • Teste em Ambiente Real:
    Utilize o DB Explorer para validar a performance e a exatidão dos resultados antes de integrá-los ao dashboard. Assim, você pode evitar problemas de lentidão ou erros de execução.

Limitações do Ambiente de Dashboards

  • Apenas SELECTs:
    O construtor de dashboards aceita somente consultas do tipo SELECT. Certifique-se de que sua query não inclua comandos de modificação ou procedimentos armazenados.

  • Funções e Sintaxes Específicas:
    Embora o SQL Server suporte uma ampla variedade de funções (como PIVOT, funções de janela, etc.), verifique se a versão do Sankhya que você utiliza permite o uso da função desejada. Teste sempre no DB Explorer ou em um ambiente de homologação.

7. Exemplos Práticos e Casos de Uso

Nesta seção, apresentamos alguns exemplos práticos que ilustram a aplicação das melhores práticas discutidas.

7.1. Exemplo de Consulta Simples com Boa Formatação

sql

-- Consulta para listar clientes ativos com informações básicas
SELECT 
    PAR.CODPARC       AS "Código do Parceiro",
    PAR.RAZAOSOCIAL   AS "Razão Social",
    PAR.NOMEFANTASIA  AS "Nome Fantasia",
    PAR.CIDADE        AS "Cidade"
FROM TGFPAR PAR
WHERE PAR.ATIVO = 1;

Pontos destacados:

  • Cada cláusula (SELECT, FROM, WHERE) está em linha separada.

  • Uso de alias (PAR) para referenciar a tabela.

  • Colunas possuem aliases de saída que facilitam a compreensão dos dados.

7.2. Exemplo com JOINs e Filtros Apropriados

sql

-- Consulta para obter informações financeiras de lançamentos vinculados a parceiros
SELECT 
    CAB.NUFIN         AS "Número Financeiro",
    CAB.DATEMISSAO    AS "Data de Emissão",
    PAR.RAZAOSOCIAL   AS "Razão Social",
    SUM(CAB.VLRDESDOB) AS "Valor Total"
FROM TGFCAB CAB
JOIN TGFPAR PAR 
    ON CAB.CODPARC = PAR.CODPARC
WHERE CAB.STATUSNOTA = 'L'
  AND CAB.TIPMOV = 'V'
  AND CAB.DATEMISSAO BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY CAB.NUFIN, CAB.DATEMISSAO, PAR.RAZAOSOCIAL
HAVING SUM(CAB.VLRDESDOB) > 1000;

Aspectos importantes:

  • Uso de JOIN com a condição explícita e filtragem dos registros com WHERE.

  • Aplicação de GROUP BY em todos os campos não agregados.

  • Uso de HAVING para filtrar resultados agregados.

7.3. Exemplo Avançado com CTE para Organizar Lógica Complexa

Imagine uma situação onde você precisa calcular o total de vendas por cliente em um determinado período, e depois unir esse resultado com informações adicionais dos clientes.

sql

-- Definindo a CTE para calcular as vendas de 2024
WITH Vendas2024 AS (
    SELECT 
        ClienteId, 
        SUM(ValorVenda) AS TotalVenda
    FROM Vendas
    WHERE DataVenda BETWEEN '2024-01-01' AND '2024-12-31'
    GROUP BY ClienteId
)
-- Consulta principal unindo os clientes com suas vendas
SELECT 
    cli.CODPARC         AS "Código do Cliente",
    cli.RAZAOSOCIAL     AS "Razão Social",
    COALESCE(v.TotalVenda, 0) AS "Total de Vendas 2024"
FROM TGFPAR cli
LEFT JOIN Vendas2024 v 
    ON cli.CODPARC = v.ClienteId
WHERE cli.ATIVO = 1;

Destaques:

  • A CTE Vendas2024 organiza a lógica de agregação, facilitando a manutenção da query.

  • A junção LEFT JOIN garante que clientes sem vendas também sejam listados, utilizando COALESCE para tratar valores nulos.

  • A separação clara entre a definição da CTE e a consulta principal torna o fluxo de dados transparente.

8. Estratégias para Manutenção e Evolução do Código SQL

8.1. Documentação Interna

  • Comentários detalhados:
    Sempre que uma lógica for complexa, adicione comentários explicando o raciocínio.
    Exemplo:

sql

-- CTE para calcular as vendas totais de 2024
WITH Vendas2024 AS (
    ...
)

  • Padronização dos comentários:
    Utilize um padrão para comentários, indicando autor, data e finalidade da query, se for necessário em projetos maiores.

8.2. Uso de Views e Stored Procedures

  • Centralize consultas recorrentes:
    Se uma query complexa é utilizada por vários dashboards ou relatórios, considere criar uma view no banco. Isso permite que a lógica seja mantida em um único local e reutilizada de forma consistente.

  • Stored Procedures para processos críticos:
    Embora o construtor de dashboards aceite apenas SELECTs, em outras áreas do ERP você pode usar stored procedures para encapsular lógicas mais complexas e garantir performance e segurança.

8.3. Controle de Versão e Repositórios

  • Armazenamento do código:
    Mantenha as consultas SQL em um repositório de código (como Git), possibilitando versionamento e histórico de alterações.

  • Padronização de nomenclatura de arquivos:
    Utilize nomes significativos para os scripts SQL, por exemplo, Clientes_Ativos.sql, Vendas2024_por_Cliente.sql, etc.

8.4. Revisões e Feedback

  • Code Reviews:
    Em ambientes colaborativos, promova revisões periódicas do código SQL. Um par de olhos extras pode identificar pontos de melhoria tanto na performance quanto na legibilidade.

  • Testes Automatizados:
    Sempre que possível, crie testes para validar que as queries retornam os resultados esperados, especialmente quando as consultas envolvem lógica complexa ou agregações críticas para os dashboards.

9. Considerações Específicas para Ambientes Sankhya

9.1. Integração com o ERP

  • Contextualização dos Dados:
    No Sankhya, muitos dados estão vinculados a variáveis de contexto, como a empresa logada, filial, ou usuário. Garanta que suas queries considerem esses parâmetros para que os dashboards exibam apenas os dados relevantes.

  • Uso de Variáveis de Ambiente:
    O Sankhya pode fornecer variáveis globais para consultas. Sempre que possível, utilize esses parâmetros para filtrar os dados sem precisar de entrada manual. Exemplo:

sql

WHERE TABELA.CODEMP = :#CODEMP

9.2. Limitações de Ferramenta

DB Explorer

  • Limite de 5.000 linhas:
    Tenha em mente que o DB Explorer limita a exibição para 5.000 registros. Se a consulta retornar mais, considere adicionar filtros para reduzir o volume de dados.

  • Ambiente de Testes:
    Use o DB Explorer para validar as queries, mas lembre-se que o ambiente de produção pode ter comportamentos distintos (por exemplo, volumes de dados maiores ou diferentes permissões).

Construtor de Dashboards

  • Preview de 20 linhas:
    Na aba de resultado do construtor de dashboards, apenas 20 linhas serão exibidas como exemplo. Essa é apenas uma amostra, portanto, teste a query em outros ambientes se precisar validar o conjunto completo.

  • Modo Avançado:
    Ao inserir a consulta manualmente, você assume total responsabilidade pela query. Certifique-se de que todas as junções, filtros e agregações estejam corretos antes de salvar o componente.

9.3. Segurança e Acesso

  • Restrições de Acesso:
    O acesso ao DB Explorer e a execução de queries SQL críticas geralmente é limitado a usuários com permissões elevadas (ex.: SUP). Planeje o uso desses recursos com base na política de segurança da empresa.

  • SQL Injection:
    Embora as consultas de dashboards sejam parametrizadas, sempre trate as entradas com cuidado. Use placeholders (:#PARAM) para evitar injeções maliciosas e garanta que os dados inseridos venham de fontes confiáveis.

10. Recomendações Finais e Boas Práticas Gerais

10.1. Clareza e Manutenibilidade

  • Simplicidade:
    Sempre que possível, escreva consultas que sejam simples e diretas. Se a lógica for complexa, quebre-a em partes (usando CTEs ou views) para facilitar o entendimento.

  • Legibilidade:
    Invista na formatação, na indentação e na utilização de comentários. Lembre-se que o código será lido por outras pessoas (ou por você mesmo no futuro).

10.2. Performance e Escalabilidade

  • Seleção de Dados:
    Selecione apenas as colunas e registros necessários. Evite carregar dados irrelevantes que possam prejudicar a performance.

  • Índices e Estrutura do Banco:
    Embora você não tenha controle direto sobre a estrutura do banco no Sankhya, conheça os índices existentes e, sempre que possível, utilize-os (ex.: filtragem por colunas indexadas).

  • Monitoramento:
    Periodicamente, revise os planos de execução das suas queries para identificar e resolver possíveis gargalos.

10.3. Evolução do Ambiente

  • Atualização Contínua:
    O ERP Sankhya e o SQL Server evoluem com o tempo. Mantenha-se atualizado com as novidades, participe de fóruns e comunidades, e adapte suas queries às melhores práticas do momento.

  • Feedback dos Usuários:
    Dashboards e relatórios são ferramentas vivas. Obtenha feedback dos usuários finais e revise as consultas para atender às novas necessidades e melhorar a experiência.

11. Considerações sobre a Documentação e Fontes de Pesquisa

Ao longo deste guia, as práticas recomendadas foram elaboradas a partir de:

  • Diretrizes e documentação oficial do ERP Sankhya.

  • Boas práticas reconhecidas na comunidade de SQL Server.

  • Experiências de desenvolvedores e administradores de banco de dados em ambientes corporativos.

É sempre recomendável consultar a documentação atualizada do Sankhya e as notas de versão do SQL Server para garantir que as práticas adotadas estejam em conformidade com as últimas atualizações e padrões.

12. Exemplos de Uso em Cenários Reais

12.1. Dashboard de Vendas

Imagine um dashboard que mostra as vendas mensais de uma empresa. A consulta pode ser estruturada da seguinte forma:

sql

WITH VendasMensais AS (
    SELECT 
        DATEPART(MONTH, DataVenda) AS Mes,
        SUM(ValorVenda) AS TotalVendas
    FROM Vendas
    WHERE DataVenda BETWEEN '2024-01-01' AND '2024-12-31'
      AND CODEMP = :#CODEMP
    GROUP BY DATEPART(MONTH, DataVenda)
)
SELECT 
    Mes,
    TotalVendas,
    CASE 
        WHEN Mes = 1 THEN 'Janeiro'
        WHEN Mes = 2 THEN 'Fevereiro'
        WHEN Mes = 3 THEN 'Março'
        WHEN Mes = 4 THEN 'Abril'
        WHEN Mes = 5 THEN 'Maio'
        WHEN Mes = 6 THEN 'Junho'
        WHEN Mes = 7 THEN 'Julho'
        WHEN Mes = 8 THEN 'Agosto'
        WHEN Mes = 9 THEN 'Setembro'
        WHEN Mes = 10 THEN 'Outubro'
        WHEN Mes = 11 THEN 'Novembro'
        WHEN Mes = 12 THEN 'Dezembro'
    END AS NomeMes
FROM VendasMensais
ORDER BY Mes;

Aspectos:

  • Uso de CTE para organizar a agregação mensal.

  • Parâmetro :#CODEMP para filtrar os dados pela empresa atual.

  • Uso de CASE para converter números de mês em nomes legíveis para o dashboard.

12.2. Relatório de Performance de Clientes

Para gerar um relatório que mostra os clientes com maior volume de vendas:

sql

WITH TotalVendasClientes AS (
    SELECT 
        ClienteId,
        SUM(ValorVenda) AS TotalVendas
    FROM Vendas
    WHERE DataVenda BETWEEN '2024-01-01' AND '2024-12-31'
      AND CODEMP = :#CODEMP
    GROUP BY ClienteId
)
SELECT 
    cli.CODPARC         AS "Código do Cliente",
    cli.RAZAOSOCIAL     AS "Razão Social",
    v.TotalVendas       AS "Total de Vendas"
FROM TGFPAR cli
JOIN TotalVendasClientes v 
    ON cli.CODPARC = v.ClienteId
WHERE cli.ATIVO = 1
ORDER BY v.TotalVendas DESC;

Aspectos:

  • Utilização de CTE para calcular o total de vendas por cliente.

  • Junção entre a tabela de clientes e a CTE para agregar dados.

  • Ordenação decrescente para destacar os clientes com maior performance.

13. Checklist Resumido de Boas Práticas

Antes de finalizar a query e implementá-la, revise os seguintes pontos:

  • Indentação e Organização:

    • Cada cláusula em linha separada.

    • Itens internos (colunas, condições) devidamente indentados.

    • Uso de espaços e linhas em branco para separar blocos lógicos.

  • Uso de CTEs e Subqueries:

    • Se a lógica é complexa ou reutilizada, prefira CTEs.

    • Se a consulta é simples e não repetitiva, uma subquery pode ser suficiente.

  • Nomenclatura Consistente:

    • Comandos SQL em maiúsculas.

    • Tabelas e colunas seguindo o padrão Sankhya.

    • Aliases claros e consistentes.

  • Filtros e Agregações:

    • Evitar SELECT *; listar apenas as colunas necessárias.

    • Aplicar filtros (WHERE) para reduzir o volume de dados antes de junções e agregações.

    • Usar HAVING apenas para condições pós-agregação.

  • Performance:

    • Utilize colunas indexadas para junções e filtros.

    • Evite funções nas colunas indexadas em condições.

    • Teste o tempo de execução e revise o plano de execução.

  • Especificidades do Sankhya:

    • No DB Explorer, esteja ciente do limite de 5.000 linhas.

    • No construtor de dashboards, use placeholders adequados (preferencialmente :#PARAM) e teste a query com o preview de 20 linhas.

    • Considere as variáveis de contexto (como CODEMP) para filtrar os dados de forma correta.

  • Documentação e Revisão:

    • Comente partes complexas da query.

    • Realize revisões de código com colegas.

    • Mantenha a documentação e versionamento das queries atualizados.

14. Conclusão

A construção de consultas SQL de forma profissional e organizada é um diferencial importante em ambientes corporativos, especialmente em sistemas críticos como o ERP Sankhya. Ao aplicar as práticas de indentação, uso de CTEs, convenções de nomenclatura e estratégias de performance descritas neste guia, você garantirá que seus dashboards e relatórios sejam confiáveis, eficientes e de fácil manutenção.

Além disso, adaptar essas práticas aos recursos específicos do Sankhya (como o DB Explorer e o construtor de dashboards) assegura que as limitações da ferramenta não comprometam a qualidade do resultado final. Lembre-se de que o ambiente e as necessidades podem evoluir, por isso, mantenha-se sempre atualizado com as melhores práticas e as atualizações do sistema.

Espero que este guia completo auxilie na criação de consultas robustas e no desenvolvimento de dashboards que agreguem valor ao negócio. Caso surjam dúvidas ou situações específicas, não hesite em consultar a documentação oficial do Sankhya ou participar de fóruns especializados para trocar experiências e aprimorar suas práticas.

Analytics
Introduction