Objetos de Banco de Dados

Todos os objetos de banco de dados seguem um padrão de nomenclatura rigoroso. Ao olhar para qualquer objeto, você deve conseguir identificar imediatamente: o que é, de qual módulo e o que faz.

Padrão Geral de Nomenclatura

TIPO_KPT_[MODULO]_[DESCRICAO]

Onde:

• TIPO: Prefixo que identifica o tipo do objeto
• KPT: Namespace Keeptor (identifica que pertence aos nossos desenvolvimentos)
• MODULO: Abreviação do módulo de negócio (3 letras)
• DESCRICAO: O que o objeto faz, em UPPER_SNAKE_CASE

Abreviações de Módulos

Dica: Se o módulo ainda não tem abreviação, defina com o Tech Lead antes de criar objetos. Sempre 3 letras.

Objetos do Dia a Dia

Estes são os objetos que você vai criar e usar na rotina de desenvolvimento em projetos de clientes.

Stored Procedures (STP)

Formato:

STP_KPT_[MODULO]_[ACAO]_[ENTIDADE]

O que são: Stored Procedures encapsulam lógica de negócio que envolve múltiplas operações no banco. Use quando a operação precisa de transação atômica, performance crítica ou manipulação de dados em lote.

Quando usar:

• Operações que envolvem múltiplas tabelas em uma transação
• Processamento em lote (batch)
• Cálculos complexos que são mais eficientes no banco
• Operações chamadas por múltiplos sistemas

Quando NÃO usar:

• CRUD simples (use a aplicação Java)
• Lógica de validação que muda frequentemente (mantenha na aplicação)

Exemplos:

Erros Comuns:

Triggers (TRG)

Formato:

TRG_KPT_[MODULO]_[TABELA]

O que são: Triggers são gatilhos automáticos que disparam quando um evento ocorre em uma tabela (INSERT, UPDATE, DELETE). O banco executa automaticamente — sem precisar chamar explicitamente.

Quando usar:

• Auditoria automática (log de quem alterou o quê)
• Manter campos calculados atualizados
• Validações que devem acontecer independente de onde vem o dado
• Sincronização entre tabelas relacionadas

Quando NÃO usar:

• Lógica de negócio complexa (use Stored Procedure)
• Chamadas externas (API, email, etc.)
• Operações demoradas (trigger bloqueia a transação)

Exemplos:

Regra Importante:

Máximo 1 trigger por tabela. Se precisar de múltiplas ações, consolide em uma única trigger com a lógica interna separada por tipo de evento (IF inserting, IF updating, etc.).

Erros Comuns:

Functions (FNC)

Formato:

FNC_KPT_[MODULO]_[ACAO]

O que são: Functions são operações que retornam um valor. Diferente de Procedures (que executam ações), Functions calculam e devolvem um resultado. Podem ser usadas diretamente em queries SQL (SELECT, WHERE, etc.).

Quando usar:

• Cálculos reutilizáveis (desconto, imposto, conversão)
• Validações que retornam verdadeiro/falso
• Formatação de dados no banco
• Transformações usadas em múltiplas queries

Quando NÃO usar:

• Operações com efeitos colaterais (INSERT, UPDATE, DELETE) — use Procedure
• Lógica que muda frequentemente — mantenha na aplicação Java

Exemplos:

Uso em Queries:

SELECT
    produto_nome,
    preco_unitario,
    FNC_KPT_FIN_CALCULAR_DESCONTO(preco_unitario, categoria_id) AS desconto
FROM TGFPRO
WHERE FNC_KPT_COM_VALIDAR_CPF(cliente_cpf) = TRUE;

Views (VW)

Formato:

VW_KPT_[MODULO]_[DESCRICAO]

O que são: Views são consultas salvas que funcionam como tabelas virtuais. Não armazenam dados — apenas definem uma query que é executada quando consultada. Simplificam queries complexas e centralizam lógica de consulta.

Quando usar:

• Relatórios que combinam múltiplas tabelas
• Consultas usadas frequentemente por múltiplas partes do sistema
• Abstrair complexidade do schema para a aplicação
• Dashboards e KPIs

Quando NÃO usar:

• Se a query é simples (SELECT de uma tabela)
• Se precisa de parâmetros dinâmicos (use Function ou Procedure)

Exemplos:

Quick Reference — Objetos do Dia a Dia

Objetos de Banco — Desenvolvimento Keeptor Interno

Os objetos abaixo são utilizados exclusivamente em desenvolvimento no banco de dados próprio da Keeptor (Plataforma Keeptor, produtos internos). Em projetos de clientes, estes objetos já existem no banco do ERP e você não precisa criá-los.

Indexes (IDX)

IDX_KPT_[TABELA]_[CAMPO(S)]

Exemplo: IDX_KPT_COM_PEDIDO_DATA, IDX_KPT_COM_PEDIDO_CLIENTE_STATUS

Regra: Toda coluna usada frequentemente em WHERE ou JOIN deve ter índice. Revise o plano de execução (EXPLAIN) antes de criar.

Primary Keys (PK)

PK_KPT_[TABELA]

Exemplo: PK_KPT_COM_PEDIDO, PK_KPT_FIN_LANCAMENTO

Foreign Keys (FK)

FK_KPT_[TABELA_ORIGEM]_[TABELA_DESTINO]

Exemplo: FK_KPT_COM_PEDIDO_CLIENTE (pedido referencia cliente)

Unique Constraints (UK)

UK_KPT_[TABELA]_[CAMPO]

Exemplo: UK_KPT_COR_USUARIO_EMAIL (email único por usuário)

Check Constraints (CK)

CK_KPT_[TABELA]_[CAMPO]

Exemplo: CK_KPT_FIN_LANCAMENTO_VALOR (valor deve ser > 0)

Sequences (SEQ)

SEQ_KPT_[MODULO]_[ENTIDADE]

Exemplo: SEQ_KPT_COM_PEDIDO (sequência numérica de pedidos)

Quick Reference — Objetos Keeptor Interno

Regra absoluta: Todo objeto de banco DEVE seguir este padrão. Objetos fora do padrão serão rejeitados.