Mostrando postagens com marcador Dicas. Mostrar todas as postagens
Mostrando postagens com marcador Dicas. Mostrar todas as postagens

sábado, 20 de abril de 2013

Criação de arquivo utilizando Select–Oracle

 

Segue dica para geração de arquivo a partir de uma consulta de forma rápida utilizando SqlPlus:

 

{
echo "set pagesize 0"
echo " Select ColunaExemplo1||','||ColunaExemplo2||','||ColunaExemplo3 ||','||ColunaExemplo4 ||','||ColunaExemplo5||','||
ColunaExemplo6||','||ColunaExemplo7||','||ColunaExemplo8 FROM Tabela_TESTE;"
} | sqlplus -s usário/Senha@Servidor >> Resultado.log

Como saída, será gerado o arquivo resultado.log com o resultado do Select, podendo esse arquivo futuramente ser importado como um CSV.

O script foi utilizado para geração de uma arquivo para uma grande massa de dados e a resposta\performance foi satisfatória.

 

Obrigado

terça-feira, 13 de novembro de 2012

Index Clustered X Nonclustered- SqlServer

 

Segue algumas das diferenças entre os dois tipos de index do SqlServer:

O tipo de index Clustered realiza a ordenação dos dados com os valores da coluna que foi selecionada para fazer parte do index, ou seja, a ordem é realizada com os próprios dados da coluna pertencente ao index. Dessa forma as informações são gravadas na tabela física na mesma ordem do index facilitando bastante a localização de registros na tabela.

Por ordenar fisicamente os dados na tabela de acordo como o valor da coluna do index, para cada tabela podemos ter apenas um index Clustered.

Apesar de melhorar o desempenho na localização de um registro, temos um tempo extra gasto com inclusões ou exclusões de dados, isso acontece pois caso seja incluído ou excluído um registro pode ser que a ordem seja alterada e que ocorra um reposicionamento dos dados.

Em uma tabela pode existir index Clustered e Nonclustered, mas devemos lembrar de sempre criar primeiramente o index Clustered já que com sua criação todos os dados serão reposicionados na tabela para assumir a ordem da coluna que ira compor o index.

O tipo de index Nonclustered funciona de maneira diferente do Clustered, ou seja, no momento da criação do index as informações físicas da tabela não são reposicionadas, ficando assim o armazenamento de ordem aleatória.

É indicado o uso de index Nonclustered quando há necessidade de localizar dados que possuem diferentes tipos de critérios, ou seja, é indicado quando na localização de registros o filtro realizada utiliza diferentes campos podendo ter um ou mais index Nonclustered para cada critério selecionado no filtro da query.

Obrigado

terça-feira, 4 de setembro de 2012

Query Notification – Sql Server

Query Notification ou notificações de consulta foi introduzido na versão Microsoft SQL Server 2005, permitindo notificar aplicativos quando os dados carregados pela aplicação, forem alterados na base de dados. Este recurso é muito útil para aplicativos que utilizam informações de banco de dados em cache (muito utilizado em aplicativos da Web) e precisam ser notificado quando os dados de origem são alterados.

As aplicações podem tirar proveito do recurso Query Notification para reduzir as idas e vindas ao banco de dados. Em vez de utilizar utilizar processos amarradas a job que são executados periodiacamente, as aplicações podem ser notificadas automaticamente quando os resultados estiverem desatualizados.

Exemplo:

Imagine uma pagina Web que exibe os 10 produtos mais vendidos na última hora, a cada nova requisição da pagina, não é necessário consultar toda a lista de pedido para identificar os mais vendidos. Podemos armazenar essa informação no Cache e utilizar do recurso Query Notification assim que a lista de produtos mais vendidos for alterada na base de dados.

Assim que o aplicativo receber a Notificação, codificamos para que seja executado um Select ou Procedure que recupera os produtos mais vendidos , limpamos e atualizamos o cache.

O Database Engine usa o Service Broker para entregar mensagens de notificação. Portanto, o Service Broker deve estar ativo no banco de dados onde o aplicativo estiver solicitando o serviço.

Para saber mais e como implementar, consulte:  http://msdn.microsoft.com/en-us/library/ms175110(v=sql.105).aspx

[]s

quarta-feira, 29 de agosto de 2012

Boas práticas ao escrever uma Procedure - SQL Server

  1. Utilize recuo/endentação adequada, pois terá melhor legibilidade melhorando seu entendimento futuro e de outras pessoas
  2. Escreva os comentários apropriados entre as lógicas para que assim, os outros possam entender rapidamente.
  3. Escreva todas as palavras-chave do SQL Server em CAPS. Por exemplo SELECT, FROM e CREATE.
  4. Procure nomear suas procedures com um nome intuitivo ao processo que ela executa
  5. Declare todas as variáveis no início da procedure
  6. Verifique o uso de variáveis desnecessárias, pois elas ocupam espaço na memória, tente reutiliza-las dentro do código
  7. Não utilizar as iniciais SP_XXX em suas procedures. Utilize como inicial Pr_XXX pois ficará mais fácil identificar suas procedures entre as nativas do Sql Server. Inclusive na própria documentação do Sql Server já diz - “Recomendamos fortemente que você não use o prefixo sp_ no nome de procedimento. Este prefixo é usado pelo SQL Server para designar procedimentos armazenados de sistema. “
  8. Defina o SET NOCOUNT ON  no início do procedimento armazenado para evitar a mensagem desnecessária, como número de linhas afetadas pelo SQL Server.
  9. Tente fazer uso de tabelas temporárias com moderação, pois elas ocupam espaço no TempDB, além disso procedimento armazenados geralmente utilizam plano de execução em Cache, com o uso de tabelas temporárias é forçada uma nova compilação.
  10. Nunca traga todas as colunas de uma consulta (SELECT *)  a não ser que for realmente necessário, use apenas colunas específicas que serão utilizadas no resultado.
  11. Tente evitar o cursor no procedimento armazenado, ele consome mais memória. Tente utilizar a variável de tabela e while loop para iterar o conjunto de resultados da consulta.
  12. Nos parâmetros de entrada da procedure, defina os types com os mesmos tamanhos e tipos das tabelas. Por exemplo, Nome Char(10) na tabela, mas você declara Nome Char(25) na procedure.
  13. Use a instrução catch Try corretamente no procedimento armazenado para lidar com os erros em tempo de execução.
  14. Se o retorno da procedure for uma única coluna/linha, prefira utilizar parâmetros de saída na procedure.
  15. Evite utilização de sub-queries ao invés disso utilize inner join
  16. Em condições de verificação de existência (exists) utilize Select top 1
  17. Em consultas  (SELECT * FROM TbProduto where id = @id) para que seu plano de execução seja reaproveitado deve ser utilizado conforme exemplo anterior, mas você estiver usando uma consulta SQL como “SELECT * FROM Tbproduto where id = "+ @ eid, dessa forma não será reutizado o plano
  18. Use o ORDER BY e DISTINCT, TOP somente quando for necessário.
  19. Verifique a necessidade de índices entre colunas de tabelas grandes que realizam joins ou filtros por essas colunas
  20. Verifique se as colunas que compõem os joins utilizam datatypes diferentes, um deles será convertido para o outro. O datatype convertido é o hierarquicamente inferior. O otimizador não consegue escolher um índice na coluna que é convertida.

[]s

sexta-feira, 10 de agosto de 2012

Conceito do banco de dados NoSQL

NoSQL é um termo utilizado para definir um tipo de banco de dados que não segue normas de tabelas (schemas) determinadas previamente. Seu significado é (Not only SQL - Não só SQL) e vem do conceito de que o banco de dados não necessita de normalização e relacionamentos.

A computação na nuvem , análises sociais, performance na consulta/escrita, replicação e a necessidade cada vez maior de prover serviços escaláveis, estão fazendo com que sejam pensadas em soluções onde se necessitem oferecer escalabilidade horizontal. Bancos de dados NoSQL armazenam os dados com técnicas que visam atender a essa necessidade.

O NoSQL surgiu dessa necessidade, ou seja, oferecer performance superior e de uma alta escalabilidade. Os bancos de dados relacionais existentes atualmente, possuem restrições a isso, sendo necessária a distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco. O NoSQL oferece a facilidade na distribuição horizontal, que em resumo é, mais dados, mais servidores, não necessariamente de alta performance. Um grande utilizador desse conceito é o Google, que usa computadores de pequeno e médio porte para a distribuição dos dados sendo essa forma muito mais eficiente e econômica.

No entanto, o banco de dados NoSQL não têm como objetivo substituir os bancos de dados relacionais, mas apenas propor algumas soluções que em determinados cenários são mais adequadas ou quanto as ferramentas de banco de dados tradicionais não são suficientes ou adequados às necessidades específicas, tais como: baixa latência, grandes volumes de dados, escalabilidade ou estruturas em que as conexões entre os dados são tão importantes quanto o próprio dado.

NoSql é um banco de dados não normalizado, que se refere ao banco de dados não seguir uma estrutura de colunas, chaves e tipos definidos previamente. No caso dos bancos NoSQL, toda a a informação necessária estará agrupada no mesmo registro, ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informação, ela estará em sua totalidade no mesmo registro.

Tipos de banco de dados NoSql

  • Key/Value Store - Esse é o tipo de banco de dados NoSQL fornecem uma chave eficiente para mapear os valores existentes, o conceito dele é uma chave e um valor para essa chave. Ele é o que aguenta mais carga de dados. Esses tipos de bancos de dados são o que tem a maior escalabilidade.
  • Wide Columns Store - Estes são também chamados de bancos de dados orientados a registro. Similar aos bancos de dados relacionais, é um banco de dados grande constituído por várias tabelas, cada uma contendo um conjunto de linhas endereçáveis. Cada linha consiste de um conjunto de valores que são considerados colunas. Fortemente inspirados pelo BigTable, do Google, eles suportam várias linhas e colunas, além de permitir subcolunas.
  • Document Store - Esses bancos de dados se concentram em armazenamento e acesso otimizado em documentos em vez de linhas ou registros, são Baseado em documentos XML ou JSON, podem ser localizados pelo seu id único ou por qualquer registro que tenha no documento. Alguns bancos de dados de documentos fornecem RDBMS.
  • Graph Store - Com uma complexibilidade maior, esses bancos de dados guardam objetos, e não registros como os outros tipos de NoSQL. A busca desses itens é feita pela navegação desses objetos.Além disso, eles enfatizam alto desempenho para acesso a dados associativo, evitando a necessidade de junção.Uma característica que o Graph DBs possuem é a capacidade de um valor do campo armazenar o ID de outra entidade.
  • Column Oriented Store - Esses são bancos de dados relacionais, porém apresentam características do NoSQL. A principal diferença deles é que os dados são armazenados em colunas, ajudando na escalabilidade.

Fontes: http://imasters.com.br - http://www.devmedia.com.br - http://www.fxplabs.com.br - http://www.nosqlbr.com.br

[]s

sábado, 21 de agosto de 2010

Criar uma árvore completa de diretórios

 mkdir -p docs/{img/{fotos,icons,wallpapers,svg},textos/{artigos,man},tmp}

A regra aqui é a seguinte:

para cada pasta que conterá subpastas use "nome/{}" dentro das chaves
coloque os nomes separados por vírgula
e não esqueça de usar o parâmetro '-p' no começo do comando!

quinta-feira, 28 de maio de 2009

BrOffice.org Zine

image

Bom a dica de hoje vai para a Revista BrOffice.org Zine, ela é a revista eletronica do BrOffice. Com periocidade mensal, ela traz noticias, tutoriais, dicas, anúncios, entrevistas e tudo o que envolve o BrOffice.org, OpenOffice.org internacional e ODF.

Se você quer colaborar entre em contato através do endereço zine@broffice.org e envie sua: crítica, dúvida, sugestão e ou elogio.

O link http://wiki.openoffice.org.br/wiki/Zine/Edicoes e baixe todas as edições publicadas da BrOffice.org Zine.

Até mais……

quarta-feira, 20 de maio de 2009

Livros Online é no O’Reillys

image

A dica de hoje é para o site http://docstore.mik.ua/orelly/ do grupo O’Reillys, neste site você encontra diversões eBooks  sobre Java, Linux, Perl, Python, Unix, Pl/Sql entre outros.

Para conferir acesse o link http://docstore.mik.ua/orelly/

quinta-feira, 30 de abril de 2009

Limpando Edits dinamicamente no Delphi

Muitas vezes precisamos limpar o conteudo de mais de um edit de tela e normalmente resolvemos o probelma da seguinte situação:

image

onde pegamos edit à edit e colocamos no evento no qual usaremos para zerar os edits, como exemplo um evento de botão Limpar ou Cancelar para podermos executar a operação no momento desejado.

Outra forma é adiconar todos os edits em algma função e usar a chamada no evento desejado.

Mas vai ai uma dica e uma das formas mais corretas de se executar esta função que é criando uma função chamando o tipo do componente que queremos limpar o seu conteúdo e no evento na qual iremos usar a função passar somente os campos que terão seu contéudo zerado apagado.

Por exemplo a função abaixo:

image 

Irá verificar se na Unit onde a mesma for chamada existe compontes do tipo TCustomEdit e irá zerar o conteúdo de todos os componentes da tela.

A figura abaixo demostra a utilização a função LimpaEdits passando como parametros os  3 edits usando no nosso exemplo:

image

Bom, espero ter ajudado, não sou nenhum expert em Delphi ou em Objetct Pascal, mas vai ai minha primeira dica em Delphi.