Planeta Arch

Fonte: http://www.catswhocode.com/blog/10-sql-tips-to-speed-up-your-database

Aproveitando a dica do @pinceladasdaweb, dei uma lida no post e vou fazer uma tradução livre aqui, acrescentando meu ponto de vista e mais algumas dicas sobre SQL em um banco de dados relacional:

1. Defina seu banco de dados com cuidado
Um bom banco de dados é um banco de dados bem desenhado, que não gera tanto trabalho para buscar as informaçoes e que não guarda dados duplicados. É um banco que tem uma estrutura clara e com nomes de tabelas e campos identificáveis.

2. Otimize o que for necessário
Nem todos os SQL que utilizaremos devem e podem ser utilizados. Mas várias instruções podem e DEVEM ser otimizadas. Para o banco cada query tem um custo, e utilizando a ferramenta e EXPLAIN, que tem em praticamente todos os bons bancos de dados, podemos ver o que está afetando mais nossa query. Cuide os joins, linhas desnecessárias, igualdades incorretas, falta de indices, etc…

3. Use algo para agilizar
Utilizar um sistema de cache é sempre muito bom, e não apenas para as querys. Pois tudo que tem que ser gerado e processado gera custo e tempo, sendo que se você já tem um resultado pronto, do que você quer, sendo q o mesmo já foi processado a algum tempo atrás é muito bom ! Isto acaba com o tráfego na rede e no processamento do banco.
No site ele cira algumas ferramentas interessantes. E devem ter outras também.

4. Não selecione o que você não precisa
Corretíssimo! Nada de “select * …” por ai heim !
Coloque na projeção do SQL ( aquela parte depois do “select” e antes do “from” ) apenas os campos que você vai precisar. Isto nos além de gerar menos custo para o banco, acaba organizando nosso retorno e padronizando a aplicação.

5. Limite o numero de linhas a serem retornadas
Geralmente o usuário final, aquele que está vendo aquela listagem de algum item na tela, não vai precisar de todos os itens que tem cadastrado na tabela. Então use paginação ! Sempre ! Limitando o número de linhas a serem retornadas do banco o custo cai ser bem menor e a resposta vai ser mais rápida. O uso de Ajax ( para web ) geralmente ajuda bastante nestes casos.

6. Não coloque chamadas ao banco dentro de loops
Organize seu código, que eu duvido que você não conseguirá unir todos os dados necessários em apenas 1 ou 2 chamadas no banco, ao invés de colocar a query em um loop. Lembre-se, que o quanto menos tiver que acessar o banco melhor !

7. Utilize JOINS ao invés de SUBQUERYs
Concordo ! A não ser em casos muito, muito complexos, não utilize subquerys, elas são muito mais pesadas e são executadas 1 vez para cada linha retornada da nossa query pai, gerando assim um custo enorme para o banco. E subquerys na projeção NEM PENSAR ! NUNCA !

8. Utilize os wildcards
Até certo ponto eu levo isto como uma feature mesmo, do SQL ansi, com o comando LIKE, do que um forma de otimização.

9. Utilize UNION ao invés de OR
Bem, eu não entendi direito o pq desta dica, até mesmo pq eu não utilizo o MySql, mas para mim isto não é válido, pois na grande maioria dos casos esta troca causará um aumento de custo ao banco, e não o contrário. Mas sempre teste sua query com mais de uma forma, talvez este seja seu caso.

10. Use Índices
Sim ! Use indices no seu banco. Mas além das PK e os indices para elas criados automaticamente, utilize somente indices em campos e tabelas que necessitarão deles. Se un indice não é utilizado em nenhum momento, em nenhuma query, exclua-o, pois ele estará gerando trabalho em vão para o banco atualizá-lo.
Como eu faço:
- Rodo a query e analiso
- Crio indices onde eu acho que deve ser criado
- Rodo a query e analiso
- Crio, altero e excluo mais algins indices onde eu acho que deve
- Rodo a query e analiso
- Excluo todos os indices que não estão sendo utilizados
- Rodo a query e analiso
- Pronto!

Geralmente estes poucos passos bastam controlar a criação de indices.

11. Triggers – Tome cuidado com elas
Elas podem nos ajudar muito, mas podem deixar o banco de dados lentão e até gerar dead-locks. Então pense bem se é realmente necessário criar tal procedimento como uma trigger.

12. Sequences/Autoincremento
Estes campos nos facilitam muito o controle das PKs e não oneram em trabalho do banco.

13. Procedimentos pesados, Batch
Estes sim eu aconselho a, sempre que possível, serem executados dentro banco.
A linguagem que roda dentro do banco de dados é muito mais ágil ao trabalhar com os dados do que ficar trazendo e enviando dados do banco até a aplicação. E isto em procedimentos que geram informações de cálculos violentíssimos, ou controles com muitos dados, e que podem demorar para rodar, podem ser colocados dentro do banco.
No PostgresSQL por exemplo, temos não somente o Pl/pgSQL, mas sim inúmeras linguagens que trabalham dentro do DB, no Oracle tem o PL/SQL, e assim vai…

No mais é o seguinte:

• Sempre teste suas querys com mais de uma forma, trocando campos de lugar, trocando a ordem dos joins e das filtragens.
• Quantos aos frameworks de banco, leia bastante na documentação como fazer para agilizar as pesquisas.
• Aprenda a alterar as principais configurações do seu banco de dados para que ele trabalhe melhor para sua aplicação, sendo que ela faz mais gravação de dados ou mais leitura de dados.
• A infra estrutura do ambiente de produção todo é muito relevante, tanto para a aplicação como para o banco. Sempre ter o banco em uma máquina separada da aplicação é ótimo!

Continuando uma série de posts sobre o ExtJS, vou falar agora sobre uma feature existente em algumas linguagens também, que é o “namespace”.

Pela wikipedia “namespace” é: “In general, a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of homonym items having the same name (residing in different namespaces).”
Traduzingo ( mal e porcamente, se puder me ajude! heheh ): “Em geral, um namespace é um recipiente genérico que contextualiza os itens (nomes ou termos técnicos, ou palavras) que contém, permitindo desambiguação de itens homônimos que tem o mesmo nome (que residem em espaços diferentes).”

No ExtJS não é diferente. Como com o Ext acabamos por gerar muitos e muitos componentes, telas, painéis e páginas completas em vários arquivos javascript, nada mais justo que organizar tudo isto separando-os em namespaces. Vejamos alguns exemplos: Digamos nosso usuario_novo.js

Ext.ns("App.NovoUsuario"); //Ext.ns é uma contração para a função Ext.namespace

App.NovoUsuario.janela = new Ext.Window({
 //...
});

E depois nosso usuario_edicao.js

Ext.ns("App.EditarUsuario");

App.EditarUsuario.janela = new Ext.Window({
 //...
});

Aqui criamos duas Windows ( não coloquei todas as propriedades pois não é o foco ) dentro de dois namespaces diferentes. Conseguimos facilmente contextualizar o que cada objeto criado faz. Isto organiza nosso código e ainda dá um limite de escopo para as variáveis e objetos ali criados.

Outra forma de utilizar o namespace é assim:

var NS = Ext.namespace("App.Modulo");
  NS.PainelDeTeste = function(cfg){
    NS.PainelDeTeste.superclass.constructor.call ... etc
  };

E

Ext.ns("App","App.Edicao","App.Criacao");
App.storegenerico = new Ext.data.Store({
 //...
});
App.Edicao.janela = new Ext.Window({
 //...
});
App.Criacao.janela = new Ext.Window({
 //...
});

Ao dar uma olhada na documentação do proprio Ext, temos uma árvore a esquerda e os dados informativos a direita.Esta árvore representa toda a estrutura montada através dos namespaces do core. E também, quando encontrarmos alguns plugins e widgtes criados por usuários, que não estão na distro padrão do Ext, geralmente estes pertencem ao ns Ext.ux, ficando assim padronizados e organizados.

Resumindo, os namespaces dão organização e legibilidade ao nosso código além de definir escopos.

até+

Links:

• http://www.jasonclawson.com/2008/05/28/extjs-using-namespaces-improved/
• http://www.extjs.com/blog/2008/05/28/use-namespaces/

Já cheguei a comentar algo aqui no blog sobre o ExtJS. Porém nunca fiz uma apresentação formal do mesmo !
Então lá vai:

O que é o ExtJS ?

O ExtJS é um framework de javascript, feito para criar aplicações na web. Com ele conseguimos criar interfaces que se parecem muito com aplicações desktop. Ele nos disponibiliza muitos componentes e funções que facilitam e muito a nossa vida.
Para se ter uma idéia de como trabalhar ( veja bem, uma idéia ! ) podemos comparar a criação de uma tela em ext com a criação de uma tela em GTK, onde vamos criando, adicionando e alinhando os itens da tela, tudo dentro de containers e layouts, mas com a facilidade de que podemos facilmente alterar seus CSS para mudar algo. Com o Ext podemos por exemplo criar uma aplicação voltada ao Adobe AIR, que roda localmente, uma aplicação completamente em Ext ou com inserido em nossa página, interagindo com nosso HTML.
Hoje, na versão 3.1, jah possui o Ext Designer bem desenvolvido, porém é pago, mas é muito bom. Ah, e falando em pago, a licença do Ext é Open-Source somente para projetos open-source, de resto se tem um preço para utilizá-lo, mas nada impede você de baixar, ler os manuais, a documentação e botar a mão na massa, sem nenhuma burocracia.

Bom, feita a primeira apresantação, vamos partir para o que interessa.

Primeiro, vamos falar um pouco de como integrar o ExtJS com sua aplicação.
O Ext trabalha muito com Ajax, de várias formas ele pode solicitar e enviar informações para um servidor web através de ajax, vejamos um exemplo:

// Um request básico
Ext.Ajax.request({
   url: 'foo.php',
   success: function(){
	  //acao a tomar...
   },
   failure: function(){
	  //acao a tomar...
   },
   headers: {
       'my-header': 'foo'
   },
   params: { foo: 'bar' }
});

// Simples envio de um formulário
Ext.Ajax.request({
    form: 'some-form',
    params: 'foo=bar'
});

No primeiro exemplo, montamos uma chamada ajax, enviando alguns parâmetros ( na propriedade: params ) e aguardamos um retorno, passando uma function na propriedade “success” que faz o que queremos, e se caso ocorrer alguma coisa errada, tratamos com a function na propriedade “failure”. Além de configurar-mos alguns cabeçalhos que serão enviados também, e obviamente para onde estamos enviando nossa requisição, na propriedade “url”.

Eu gosto muito de trabalhar assim com o Ajax, desta forma exemplificada acima, pois fico livre para enviar e aguardar dados da forma que eu quiser, apesar de ter alguns frameworks que integram as chamadas ajax com a linguagem escolhida, mas assim, dando uma engessada no negócio.

Outro detalhe importante: JSON !
Todo o ExtJS trabalha com Json ( mas não só JSON ), tanto para montar os objetos e componentes da tela, como para enviar dados para o servidor, e trabalhar com Json em tudo, primeiro padroniza todo o ambiente, e segundo, facilita muito a nossa vida, pois o Json é simples e muito completo. Com ele conseguimos criar muitos objetos e enviar vários tipos de dados. Então caso não conheça bem o json, dê uma olhada aqui: http://www.json.org/

Muitos objetos do Ext trabalham com dados remotos, ou seja, aguardam que o servidor envie os itens a serem mostrados na tela, como por exemplo: combos, grids, trees, e por ai vai… este exemplo acima é um exemplo de chamada ajax solta, no meio da página, que pode ser chamada de qualquer ponto, e para qualquer intuito, porém, nos componentes a chama do ajax é feita automaticamente pelos “Store” ! hehehe

Bom, outro ponto que acho muito importante também no Ext é o chamado “Store”. O Store é um objeto que age de forma a nos possibilitar ver e alterar muitos registros de dados que por nós foram definidos. É como se fosse um Recordset por exemplo, só que mais maleável. O Store pode estar ligado a um grid, combo, e outros componentes, e até solto, sem estar ligado a componente algum, e pode ter vários modos de leitura, como por exemplo: xml, json e um simples array de dados.

Para você ter uma idéia de como pode ficar bonita uma aplicação feita com o Ext, veja este link: http://www.extjs.com/deploy/dev/examples/forum/forum.html

Agora, alguns links para você poder saber mais:

Site oficial: http://www.extjs.com
Site de Exemplos: http://www.extjs.com/deploy/dev/examples/
Documentação:  http://www.extjs.com/deploy/dev/docs/

Feitas estar primeiras introduções sobre o Ext, fiquem no aguardo do proximo post sobre o Ext.
Até lá.