Estive precisando otimizar a consulta em uma mega estrutura de dados, a principio estava usando LIKE, mas logo de inicio foi falado que precisariamos de uma consulta usando Full Text Search.
Eu sabia muito pouco do conceito do FTS, pois em nenhum momento precisei usar no nível que a equipe precisava.
Então eu comecei a pesquisar, encontrei muitos conceitos e pouco prática...
Então resolvi ir direto na fonte, rs...acessei o conteudo de referencia no Postgres e comecei a estudar o FTS.
Estudei e comparei com tudo que eu já havia achado na internet...então percebi que as pessoas enchiam muito os textos pra dizer que sabiam, que tinham o total conhecimento etc...etc...etc.
Comecei os meus testes e percebi que pra voce ter um resultado satisfatório nao precisava de muita enganação, bastava ir direto ao assunto.
Mas voce precisa pelo menos entender alguns conceitos do FTS, senão por menor que seja o meu código voce vai ficar perdido.
O FTS (Full Text Search) é uma técnica de pesquisa e recuperação de dados no formato texto armazenada em banco de dados, usando PL/SQL.
Na busca Textual com FTS voce podera fazer uma indexação completa de texto e pré-processar documentos salvando na própria entidade(tuplas). Voce podera fazer uso de Dicionários.
No FTS existe: GiST e GIN
GIN ele efetua pesquisas aproximadamente três vezes mais rápido do que GiST;
GIN demoram aproximadamente três vezes mais para serem construídos do que GiST;
GIN são mais lentos para atualização de índices;
GiST são mais rápidos para atualização de índices;
Usar GiST ou GIN no FTS?
Regra básica e usar índices GIN para dados estáticos, porque as pesquisas são mais rápidas.
E índices GiST para dados que são dinâmicos, porque são mais rápidos para atualização.
Vamos na prática.
1 - Eu criei uma tabela noticias, que tem os seguintes campos: id_noticia, titulo, texto_intro, texto
2 - Altero a tabela adicionando um novo campo do tipo tsvector
ALTER TABLE noticias ADD busca tsvector;
3 - Criei o indice
CREATE INDEX noticias_gidx ON noticias USING gin(busca);
4 - Criei uma funcção pra poder criticar todos os caracteres desconhecidos.
CREATE FUNCTION to_ascii(bytea, name) RETURNS text AS
'to_ascii_encname'
LANGUAGE internal STRICT;
5 - Criei uma função que trata os valores com caracteres desconhecidos e retorna os valores tratados.
CREATE FUNCTION simples(texto varchar) RETURNS varchar AS
'select lower(to_ascii(convert_to($1, ''latin1''), ''latin1''))'
LANGUAGE sql IMMUTABLE STRICT;
6 - Atualizo o campo que eu criei 'busca' com o valores acrescentando tambem um peso pra cada item indexado no meu tratamento.
UPDATE noticias SET busca = to_tsvector('portuguese',simples(titulo));
UPDATE noticias SET busca = setweight(to_tsvector('portuguese',coalesce(titulo,'')), 'A') ||
setweight(to_tsvector('portuguese',coalesce(texto,'')), 'B') ||
setweight(to_tsvector('portuguese',coalesce(texto_intro,'')), 'C') ;
Pronto....
Agora e so testar...
EXPLAIN SELECT id_noticia, titulo FROM noticias
WHERE busca @@ plainto_tsquery(simples('brasil equipe'));
SELECT
titulo,
ts_rank_cd('{0.8, 0.6, 0.4, 0.0}', busca, to_tsquery('brasil')) AS rank
FROM noticias
WHERE busca @@@ to_tsquery(simples('brasil'))
ORDER BY rank DESC;
Obrigado a todos...
segunda-feira, 9 de julho de 2012
sexta-feira, 6 de julho de 2012
Um pouco de Gerência de Projetos (Equipe)
Esse é a última parte da nossa conversa sobre Gerencia de Projeto.
Estarei neste tópico falando um pouco sobre equipe.
Cada integrante da equipe envolvido no projeto são conhecidos como os 'stakeholders' (parte interessada).
É importante que o gerente do projeto conheça os interesses de todos os envolvidos.
No momento em que estiver definindo o escopo, o Gerente de Projeto vai saber quais habilidades serão necessárias. Esse vai ser o momento de formar a equipe com experiência necessárias para o projeto. Em alguns projetos existe muito conhecimento técnico envolvido...devido a isso o Gerente de Projeto deverá buscar a ajuda de um 'líder de projeto'. Esse líde deverá ser um profissional de alto conhecimento técnico e com capacidade de liderança. Não pode ser um profissional pleno, mas de preferência um sênior, com fácil acesso aos demais integrantes da equipe.
O líder de projeto deverá ser o 'braço direito' do Gerente de Projeto. Faça de tudo pra ele estar sempre do seu lado. Pois ele será seu guia, sua ajuda.
Estarei neste tópico falando um pouco sobre equipe.
Cada integrante da equipe envolvido no projeto são conhecidos como os 'stakeholders' (parte interessada).
É importante que o gerente do projeto conheça os interesses de todos os envolvidos.
No momento em que estiver definindo o escopo, o Gerente de Projeto vai saber quais habilidades serão necessárias. Esse vai ser o momento de formar a equipe com experiência necessárias para o projeto. Em alguns projetos existe muito conhecimento técnico envolvido...devido a isso o Gerente de Projeto deverá buscar a ajuda de um 'líder de projeto'. Esse líde deverá ser um profissional de alto conhecimento técnico e com capacidade de liderança. Não pode ser um profissional pleno, mas de preferência um sênior, com fácil acesso aos demais integrantes da equipe.
O líder de projeto deverá ser o 'braço direito' do Gerente de Projeto. Faça de tudo pra ele estar sempre do seu lado. Pois ele será seu guia, sua ajuda.
A equipe deverá ter competência têcnica para a viabilização das soluções propostas, respeitando a diversidade, tendo uma postura ética com transparência e profissionalismo. Deverá respeitar os relacionamentos interpessoais e ter proatividade nas ações e ser um agente de mudanças.
Sempre envolva sua equipe, fazendo que eles se sintam responsáveis pelo projeto.
Espero que tenham aproveitado a leitura.
Obrigado a todos.
Espero que tenham aproveitado a leitura.
Obrigado a todos.
quinta-feira, 5 de julho de 2012
Um pouco de Gerência de Projetos (Escopo)
Hoje vou falar um pouco sobre 'Escopo de Projeto'.
Isso é complicado, já vi cada escopo de dar medo.
Para que um escopo tenha o resultado desejado, que é, ter um projeto finalizado com os recursos necessários e funcionais, você tem que separar o 'joio do trigo', ou seja, definir o que deve ser feito e o que não deve ser feito, pelo menos na fase inicial do projeto.
Pessoas que não tem muito conhecimento deixam se levar por discussões que se extendem por horas e até dias buscando soluções que vão deixar o projeto final totalmente 'perfeito'. Isso é bom...mas na maioria das vezes atrapalha e leva a um desgaste desnecessário. Gastando horas preciosas.
O Gerente de Projeto tem que mostrar e deixar bem claro pro cliente que não é por que um determinado recurso não está sendo implementado agora, que ele vai ficar fora do escopo. Mas que o mesmo poderá ser implementado em uma segunda ou terceira versão. Pois o foco principal no presente momento é fechar uma versão com as funcionalidades principais. E depois o projeto vai sendo melhorado, agregando as funcionalidades que ficaram de fora da primeira versão.
Pessoas que não tem muito conhecimento deixam se levar por discussões que se extendem por horas e até dias buscando soluções que vão deixar o projeto final totalmente 'perfeito'. Isso é bom...mas na maioria das vezes atrapalha e leva a um desgaste desnecessário. Gastando horas preciosas.
O Gerente de Projeto tem que mostrar e deixar bem claro pro cliente que não é por que um determinado recurso não está sendo implementado agora, que ele vai ficar fora do escopo. Mas que o mesmo poderá ser implementado em uma segunda ou terceira versão. Pois o foco principal no presente momento é fechar uma versão com as funcionalidades principais. E depois o projeto vai sendo melhorado, agregando as funcionalidades que ficaram de fora da primeira versão.
O Gerente de Projeto não pode trabalhar com a palavra 'perfeição', trabalhe focado na entrega de um projeto sem erros, com todas a funciolidades corretas e de comum acordo com o cliente. O projeto perfeito te leva pra longe do projeto entregue.
Defina com o cliente as funcionalidades principais que ele gostaria que fosse entregue em uma primeira versão. Fique atento para que o as funcionalidades da segunda ou terceira versão sejam 'camufladas' em funcionalidades de primeira versão.
O Gerente de Projeto ele tem que ser frio no momento de definir o que deve ficar fora e o que deverá ficar pra fases posteriores.
O escopo depois de fechado ele tem que ser protegido, blindado.
Projetos que tem seu escopo sendo alterado constantemente durante seu desenvolvimento possui sérias dificuldades de não cumprir o cronograma e estourar o orçamento, e muitas vezes levam o projeto ao fracasso.
Defina com o cliente as funcionalidades principais que ele gostaria que fosse entregue em uma primeira versão. Fique atento para que o as funcionalidades da segunda ou terceira versão sejam 'camufladas' em funcionalidades de primeira versão.
O Gerente de Projeto ele tem que ser frio no momento de definir o que deve ficar fora e o que deverá ficar pra fases posteriores.
O escopo depois de fechado ele tem que ser protegido, blindado.
Projetos que tem seu escopo sendo alterado constantemente durante seu desenvolvimento possui sérias dificuldades de não cumprir o cronograma e estourar o orçamento, e muitas vezes levam o projeto ao fracasso.
O problema mais comum no escopo de um projeto é o que se chama de 'scope creep', também conhecido como 'goldplating', refere-se a fornecer escopo adicional, algo que não foi definido, solicitado ou até mesmo aprovado.
O Gerente de Projeto tem que ter como meta, entregar ao cliente somente o que ele solicitou e nada a mais ou a menos. Acrescentar funcionalidades extras ao projeto produz perda de tempo e não faz bem a saúde do projeto.
Em breve estarei fechando esse conjundo de idéias falando sobre equipe.
Obrigado.
terça-feira, 3 de julho de 2012
Um pouco de Gerência de Projetos
Despois de ter visto muitas pessoas se intitulando 'Gerentes de Projetos' resolvi escrever algumas linhas falando um pouco sobre esse assunto.
Hoje em dia é fácil encontrar pessoas se achando mega Gerente de Projetos, trazendo dores de cabeça pra equipe de desenvolvimento, clientes e principalmente pra empresa ao qual ele presta esse tipo de serviço.
Pessoas que não sabem nem o que significa XP (Windows XP???) - NÃÃÃÃÃOOOOOOO..............
XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.
Metodologia XP: comunicação, simplicidade, feedback, coragem e respeito.
Pois é, rs, isso que vou falar agora é verdade. Pessoas que se diziam Gerentes de Projetos questionaram se XP ao qual eu estava falando era o Sistema Operacional do Windows................rs...parei...pensei...não respondi...dei meia volta e sai...rs....é muito complicado responder...rs.
É muito complicado quando você vira pro seu 'Gerente' fala pra ele acessar o MER (Modelo de Endidades e Relacionamentos), DER (Diagrama de Entidades e Relaciomanentos)...e ele olhar pra você com uma cara de que nao esta entendendo nada do que voce esta falando...parece que estou falando MER-DE(A)R...
Uma vez estava explicando algumas funções criadas dentro do Postgres para o meu 'Gerente', ele vira pra mim e pergunta: - O que é postgres????
Bem, eu parei...pensei (Tô F...)....com muita calma eu falei: É o SGDB (Sistema de Gerenciamento de Banco de Dados) que estamos usando nesse projeto...
Pergunta: - O que é SGDB???
Mudei de assunto e expliquei o básico das funcionalidades pois sabia que ele não estava entendendo nada mesmo.
Para que um projeto tenha o resultado esperado tem que se escolher qual vai ser a metodologia usada.
Uma metodologia é uma forma de você ter um maior controle sobre os recuros que serão utilizados em um determinado projeto. Esse conjunto de regras (a metodologia), vai conduzir com sucesso o seu projeto.
Hoje em dia temos a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. E quem criou a UML desenvolveu o RUP (Rational Unified Process) que é uma metodologia muito conhecida.
No dia - a - dia do projeto poderá existir alguns momentos aonde a falta de comunicação deixa disseminar informações que podem acabar com a moral da equipe (conversas paralelas, fofocas, boatos etc). O Gerente de Projeto deve ficar fora e não se envolver. Ele tem a obrigação de passar informações confiáveis sobre o status do projeto.
Para todo problema encontrado deve-se buscar uma solução...problemas sem soluções trazem aborrecimentos para equipe, cliente e toda empresa.
Espero que aproveitem o texto eu continuo amanhã...
Hoje em dia é fácil encontrar pessoas se achando mega Gerente de Projetos, trazendo dores de cabeça pra equipe de desenvolvimento, clientes e principalmente pra empresa ao qual ele presta esse tipo de serviço.
Pessoas que não sabem nem o que significa XP (Windows XP???) - NÃÃÃÃÃOOOOOOO..............
XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança.
Metodologia XP: comunicação, simplicidade, feedback, coragem e respeito.
Pois é, rs, isso que vou falar agora é verdade. Pessoas que se diziam Gerentes de Projetos questionaram se XP ao qual eu estava falando era o Sistema Operacional do Windows................rs...parei...pensei...não respondi...dei meia volta e sai...rs....é muito complicado responder...rs.
É muito complicado quando você vira pro seu 'Gerente' fala pra ele acessar o MER (Modelo de Endidades e Relacionamentos), DER (Diagrama de Entidades e Relaciomanentos)...e ele olhar pra você com uma cara de que nao esta entendendo nada do que voce esta falando...parece que estou falando MER-DE(A)R...
Uma vez estava explicando algumas funções criadas dentro do Postgres para o meu 'Gerente', ele vira pra mim e pergunta: - O que é postgres????
Bem, eu parei...pensei (Tô F...)....com muita calma eu falei: É o SGDB (Sistema de Gerenciamento de Banco de Dados) que estamos usando nesse projeto...
Pergunta: - O que é SGDB???
Mudei de assunto e expliquei o básico das funcionalidades pois sabia que ele não estava entendendo nada mesmo.
Para que um projeto tenha o resultado esperado tem que se escolher qual vai ser a metodologia usada.
Uma metodologia é uma forma de você ter um maior controle sobre os recuros que serão utilizados em um determinado projeto. Esse conjunto de regras (a metodologia), vai conduzir com sucesso o seu projeto.
Hoje em dia temos a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. E quem criou a UML desenvolveu o RUP (Rational Unified Process) que é uma metodologia muito conhecida.
No dia - a - dia do projeto poderá existir alguns momentos aonde a falta de comunicação deixa disseminar informações que podem acabar com a moral da equipe (conversas paralelas, fofocas, boatos etc). O Gerente de Projeto deve ficar fora e não se envolver. Ele tem a obrigação de passar informações confiáveis sobre o status do projeto.
Para todo problema encontrado deve-se buscar uma solução...problemas sem soluções trazem aborrecimentos para equipe, cliente e toda empresa.
Espero que aproveitem o texto eu continuo amanhã...
Assinar:
Postagens (Atom)