Desenvolvimento Código Aberto

A grande maioria das empresas necessitam de sistemas que possam processar, guardar e manipular informações e o modo mais comum de se fazer este trabalho é usando um banco de dados relacional. Um sistema de gerenciamento de banco de dados relacional (RDBMS) é um sistema de gerenciamento de banco de dados (SGBD), que é baseado no modelo relacional introduzido por EF Codd, do Laboratório de Pesquisa de San Jose da IBM. Muitos bancos de dados populares atualmente em uso são baseados no modelo de banco de dados relacional.

Os RDBMSs tornaram-se uma escolha predominante para o armazenamento de informações em bancos de dados, usados para registros financeiros, fabricação e informações logísticas, dados de pessoal, e muito mais desde 1980. Bancos de dados relacionais, muitas vezes substituindo bancos de dados hierárquicos e bancos de dados de rede, porque eles são mais fáceis de entender e usar. No entanto, os bancos de dados relacionais vem sendo substituídos por banco de dados orientados a objeto que foram introduzidos na tentativa de resolver a diferença de impedância objeto-relacional em banco de dados relacional e bancos de dados XML.

Entre os maiores banco de dados relacionais do mercado, segundo a empresa Gartner, os líderes de vendas são:

1. Oracle (48.8%),
2. IBM (20.2%),
3. Microsoft (17.0%),
4. SAP incluindo (Sybase (4.6%), e Teradata (3.7%))

Banco de dados o grande vilão

Quem já ouviu esta afirmação? “O sistema está muito lento!”. Existem vários fatores que podem causar este problema mas eu já ouvi o que considero a pior resposta do mundo de para esta afirmação e foi de um especialista da empresa líder nacional do mercado para ERP, da qual você já imaginou o nome. O sistema estava em um cliente multinacional que fabrica peças para montadoras de carros e rodava sobre o banco de dados Microsoft SQL Server, e o consultor da tal empresa  disse: “Troca o banco de dados pelo Oracle“. Instantaneamente o gerente de TI  replicou: “Neste caso é melhor eu trocar seu sistema pelo SAP!”.

Eu concordo plenamente com a resposta do gerente de TI da multinacional, o SAP roda muito bem em SQL Server e atende a maioria das empresas no qual utiliza esta configuração e benchmark dos dois bancos de dados são comuns, basta procurar no Google, segue aqui um exemplo : BenchMark DB2 1o vs SQL Server 2012 vs Oracle 11g R2 . Será que todas as empresas utilizam as novas features dos bancos de dados em seu sistema assim como faz a SAP?

Geralmente a solução do problema é trazida por um empresa de consultoria, porque este tipo de empresa lida com vários bancos de dados, de vários sistemas diferentes e seus especialistas conhecem a fundo varias bases de dados dos mais diferentes tipos, incluindo sistemas como o SAP, JDEdwards,  MS Dynamics. É comum algumas consultorias que também fabricam software desenvolver soluções que completam ou interagem com estes ERPs e estes desenvolvedores ou consultores já estão calejados e sabem que nem tudo que existe por ai é uma maravilha, e nem todos podem ter o luxo de utilizar uma base de dados criada e assinada pela SAP, Oracle, Microsoft ou IBM. E as vezes ou na maioria delas a melhor solução é sim trocar o sistema.

O que acontece por ai?

Algumas empresas não sabem utilizar corretamente o banco, ressalto que utilizar um o banco de dados não é apenas possuir um desenvolvedor SQL que saiba escrever scripts. Já presenciei sistemas de empresas que existem há mais de 10 anos no mercado e ainda não aprenderam a utilizar um banco de dados relacional corretamente, muito menos já seguiram algum dia as melhores praticas. Em um caso em particular o banco de dados era Oracle e o sistema rodava em clientes de médio porte, e a frase constantemente ouvida dos clientes era: “O sistema é muito lento e toda vez que atualiza o sistema gera muitos erros”. Bom, neste caso o especialista da empresa não poderia dizer para trocar o banco de dados e ao analisar a base dados instantaneamente se notava vários problemas como: muitas chaves primarias, a não utilização de índice único, triggers em excesso, scripts SQL no mínimo duvidosos e lembro de um script do relatório de inventario que demorava mais ou menos 10 minutos para retornar 750 produtos.

É! isto existe por ai! E pergunto para você, isto é normal?

Alguns casos são demorados de resolver como o caso da empresa acima que vinha costurando scripts e programação sem metodologia a mais de 10 anos em um banco sem normalização e outros podem ser resolvidos facilmente como o caso de um empresa cooperativa de grande porte que possuía outras 98 empresas em seu grupo e precisava importar as notas fiscais de todas as empresas para um sistema de validação fiscal  que utiliza Microsoft SQL Server e os dados seriam extraídos de um sistema da IBM, este processo demorava mais de 4 horas . Utilizando novos scripts SQL, implementando técnicas de BULK foi possível reduzir o tempo do processo para importação de 5 anos de dados  de 98 empresas para 15 minutos.

O Verdadeiro Vilão

Podemos apontar de primeira alguns dos principais problemas como, falta de conhecimento da documentação do banco de dados em questão, pouca ou nenhuma normalização, não tratar o modelo de dados como um organismo vivo, que respira e cresce constantemente, o armazenamento inadequado dos dados de referência, não usar chaves estrangeiras ou restrições de verificação ou o uso excessivo dos mesmos, o não uso de domínios e padrões de nomenclatura  e não escolher chaves primárias adequadamente.

Em segundo lugar está o estilo de programação tanto para os scripts do banco dados como na linguagem que acessa os dados, é comum encontrar o uso excessivo de cursores, acessos repetitivos e não saber quando usar o conceito de múltiplos bancos de dados.

Vou ilustrar os parágrafos acima com um outro caso que também é muito comum, e refere-se a uso excessivo de chaves estrangeiras,  não saber a hora de optar por um sistema de banco de dados múltiplos e não incluir no projeto do sistema a previsão de crescimento do mesmo.

O problema ocorre porque inicialmente o projeto de um tipo de ferramenta que extrai dados fiscais para validação foi escrito somente para o banco de dados Oracle, ao longo dos anos com o investimento da Microsoft no MSSQL Server o banco de dados conseguiu um bom espaço no mercado e varias empresas de médio e grande porte o adquiriram, então a ferramenta da empresa em questão precisava trabalhar e rodar nos dois banco de dados. Mas o trabalho era árduo porque era preciso extrair os últimos cinco anos de dados fiscais da empresa e suas filiais e valida-los em horas.

Com o passar dos anos as obrigatoriedades vieram a ser maiores e a empresa proprietária da ferramenta precisava atender estas obrigatoriedades e o próprio mercado ditou a necessidade da ferramenta estar apta a rodar em um banco de dados que vinha ganhando cada vez mais espaço, é obvio que se um cliente possuísse uma licença para o banco de dados que rodava em seu sistema principal (MSSQL) não iria comprar uma licença mais cara (Oracle) somente para poder utilizar uma ferramenta e sim procurar outra ferramenta que atendia sua especificação técnica.

Primeiro a empresa tentou sozinha desenvolver para o novo banco de dados e encontrou varias dificuldades ao ter que descobrir também sozinha que os conceitos entre os bancos de dados não eram iguais e decidiu procurar ajuda especializada, ficou surpresa com o resultado, ao trabalhar com mais de um banco de dados a empresa conseguiu benefícios de desempenho também para o banco de dados no qual a empresa dominava e era especialista.

Porque para competir com o Oracle a Microsoft também usou como estratégia restringir os erros cometidos pelos desenvolvedores na arquitetura do banco de dados, meio que forçando o banco de dados SQL Server a ser escrito e normalizado o mais corretamente possível, assim ganhando mais performance, um exemplo são as chaves estrangeiras, estas requerem memoria e custam para serem interpretadas pelo Engine do banco de dados e a partir da versão 2005 do MSSQL a Microsoft começou a restringir chaves estrangeiras por tabela. No caso de um banco de dados único em um sistema multi-empresas é comum possuir mais de 253 tabelas que possuem uma chave estrangeira conectada a tabela de empresas, então a Microsoft começou a emitir um erro quando se tentava deletar ou alterar um registro de uma tabela que possuía tal quantidade de chaves estrangeiras, a simples clausula executada sobre esta tabela:

Delete from EMPRESA where ID_EMPRESA = 1

retorna o seguinte erro: QUERY TOO COMPLEX.

Capacidade máxima do MSSQL Server (Atente-se para a coluna chamada Foreign key table references per table):

link: http://msdn.microsoft.com/en-us/library/ms143432.aspx

Você pode ler e inserir dados na tabela normalmente, mas não pode mais apagar ou alterar os dados devido ao alto custo da query, apesar do Oracle ou outros bancos de dados permitirem tal modelagem a query executada sobre estas circunstancias também terá um custo maior para ser resolvida pelo Engine do banco de dados. Para uma modelagem mais compacta e sem excessos de objetos no banco de dados, um sistema pode possuir múltiplos bancos de dados, um exemplo de um sistema de grande porte com múltiplos bancos de dados é o JDEdwards da Oracle.

Processamento de grandes volumes de dados

É recomendado seguir melhores praticas para cada banco de dados e ler os White Papers escritos para suas ferramentas e quanto a regras de programação para sistemas que acessam dados você pode seguir o critério acima ou pode buscar conhecimento em empresas que já possuem este know-how como o caso da SAP.

Como é de conhecimento de todos os sistemas da SAP foram projetados para trabalhar com grande volume de dados e a SAP especifica 5 regras para se programar com os banco de dados: Oracle, Db2, Microsoft SQL Server e Informix. Apesar destas regras serem escritas para programas ABAP e Java e a arquitetura de dados do SAP R/3, elas também se aplicam a forma como outras linguagens de programação devem acessar o banco de dados:

1. Mantenha o conjunto de resultados Pequeno.
2. Minimizar a quantidade de dados transferidos.
3. Minimizar o número de transferências de dados.
4. Minimizar a Pesquisa Overhead.
5. Reduzir a carga do banco de dados.