Tag Banco de Dados

Padrões de desenvolvimento do ERP CIGAM para Bancos de Dados

Leandro de Matos Machado

Em tempos como o de hoje, onde as aplicações em geral cada vez mais precisam ter o máximo de performance para executar suas tarefas, um grande vilão torna-se o processamento de informações contidas no banco de dados. De certa forma não se pode fugir dessa realidade, ou desse caminho obrigatório a ser percorrido, mas podemos encurtar esse trajeto mudando o local desse processamento dos dados.

Para isso, podemos utilizar o processamento pesado, ou seja, aquelas enormes regras de negócios das rotinas do ERP CIGAM diretamente no banco de dados. Podemos fazer isso sem qualquer problema através de stored-procedures, functions, triggers dentre outros objetos de bancos disponíveis em banco de dados como Oracle e SqlServer.

Nesse ponto existe um consenso quase geral, inclusive alavancado por grandes nomes e tecnologias, citando, como por exemplo, a Microsoft e o .Net Framework respectivamente. Não basta apenas escrever código para objetos de banco ou consultas, também é preciso manter uma padronização de maneira que facilite a manutenção, bem como as evoluções.

Seria uma maravilha se pudéssemos desenvolver o ERP CIGAM para apenas um banco de dados, e no momento da venda o cliente se disponibilizasse a utilizar esse banco de dados “obrigatório”. Infelizmente, isso não é possível nos dias de hoje, considerando que o cliente já pode estar utilizando um banco de dados para outros aplicativos ou até mesmo outros módulos e rotinas em que se deseja que o ERP CIGAM integre.

Neste artigo veremos algumas características dos padrões adotados para o desenvolvimento de objetos de banco de dados, considerando principalmente a realidade que o CIGAM roda em diferentes bancos de dados com a mesma aplicação e que existirão objetos de bancos equivalentes em ambos os bancos.

O padrão

Em breve iremos disponibilizar para toda a Rede CIGAM o Padrão de desenvolvimento CIGAM (PDC). O PDC irá agrupar todos os nossos documentos que falam sobre padronização (interface, banco de dados, regras de programação, etc). Especificamente sobre o padrão de desenvolvimento para bancos de dados, este capítulo tem por objetivo detalhar a forma de escrever o código do objeto ou da consulta SQL que é utilizada diretamente no ‘SQL-Command’ do uniPaaS.  Nesse capítulo encontram-se, ainda, as regras, desde a capitalização dos caracteres, indentação, como até mesmo recursos que não devem ser utilizados, servindo como base e referência para todos os programadores e, inclusive, testadores. Sempre que os padrões forem alterados, quase sempre por inclusões, todos os afetados serão notificados para que possam fazer a leitura de revisão e adequação.

Existem muitos tópicos considerados importantes, ou seja, itens que se não cumpridos tornam o objeto ou consulta totalmente incompatível com as definições propostas. Hoje, porém, vou destacar somente alguns deles para conhecermos um pouco melhor:

 

Nomes

Os nomes dos objetos obedecem a um padrão que identifica pelo prefixo o tipo do objeto. Isso identifica claramente o tipo do objeto além de facilitar a localização em caso de depurações ou manutenção das rotinas. Exemplos:

  • Stored-procedures devem ter o nome iniciando com “CGPR_”, como CGPR_CALCULA_PLANO
  • Triggers terão o nome iniciando com “CGTR_”, como CGTR_EXCLUI_PARADAS
  • Views com “CGVW_”, como CGVW_ALOCACOES_DIARIAS

Arquivos de scripts

Cada objeto será contido em um arquivo, como o mesmo nome do objeto nele contido e com a extensão de acordo com o tipo do objeto.

Além de identificar de maneira clara a rotina da aplicação de manutenção consegue identificar e seqüenciar adequadamente os objetos no momento da criação em lote. A extensão do arquivo também está padronizada de acordo com o tipo do objeto. Exemplos:

  • O script de criação da stored-procedure “CGPR_CALCULA_PLANO” será contido no arquivo “CGPR_CALCULA_PLANO.prc”
  • O script de criação da view “CGVW_ALOCACOES_DIARIAS” será contido no arquivo “CGVW_ALOCACOES_DIARIAS.vew”

SQL Ansi

Sempre optar pelo SQl Ansi, ou seja, o padrão de código que é comum entre todos os bancos de dados. Quando um recurso/função existe apenas em um banco de dados, não deverá ser utilizado, pois no momento da conversão isso fará que existam diferenças na estrutura do objeto ou mais (ou menos) objetos que na versão para outro banco. Sempre que criado um objeto para um banco, o mesmo deverá existir no outro banco também. Caso o recurso/função não comprometa a estrutura de objetos citada anteriormente, deve ser criado o equivalente no banco em que não existe. Exemplo:

  • No Oracle existe a função ‘LPad’, inexistente no SqlServer. Para utilização, foi criada a função “CGFC_LPAD” para SqlServer

Conversão

O desenvolvimento é feito para um banco de dados e apenas convertido para o outro. Não confunda conversão com reprogramação. A conversão consiste em apenas mudar a sintaxe dos objetos para o outro banco, mantendo a regra de negócio idêntica.  Isso facilita muito as manutenções, pois quando alterado em um banco pode-se identificar as mesmas variáveis, cursores, condições, blocos de repetições, etc, no objeto do outro banco.

Nomes-lógicos

Nem todos os clientes utilizam as mesmas traduções para os nomes-lógicos. Neste caso, o script de criação do objeto deve conter uma seqüência especial de caracteres para que a rotina de manutenção possa identificá-los e traduzi-los no momento da criação do objeto. Exemplo:

select cd_material

from /*nl<ESMATERIAL>*/ESMATERI

No momento da criação do objeto, a rotina de criação substituirá o texto “/*nl<ESMATERIAL>*/ESMATERI” pela tradução do nome-lógico %ESMATERIAL%.  Notamos também que em tempo de desenvolvimento a instrução acima é perfeitamente válida, tornando possível a codificação com os nomes de objetos existentes naquele ambiente.

Acabamos de conhecer um pouco dos padrões de desenvolvimento para objetos e consulta de bancos de dados adotados para o desenvolvimento do CIGAM.  Para maiores informações, verifiquem o documento na íntegra.

Até a próxima.

Leandro de Matos Machado
Programador de Sistemas / CIGAM Software Corporativo