[Resolvido] busca fulltext search e organização do db - tipo blog

Sander Luís · Junho 21, 2012

ADMIM EXCLUA O OUTRO TOPICO Q CRIUO DUPLICADO QUANDO ACALQUEI EM POSTAR PARECIA QUE NÃO TINHA IDO E CLIQUEI EM POSTAR DENOVO E CRIOU 2..

assim pessoal to fazendo um projeto grande, mas presiso de umas dicas de como fazer da melhor forma a organização no banco de dados...

primeiro, a busca no db será com varias palavras, achei isso: http://dev.mysql.com/doc/refman/4.1/pt/fulltext-search.html

segundo, digamos que na categoria noticias, terei milhares de linhas contendo titulo, data, quem postou,tags,categoria...

presiso fazer uma busca rapida..

então achei isso: http://vivendonaweb.blogspot.com.br/2010/05/banco-de-dados-e-seus-indices.html

agora... presiso de dicas...

a estrutura do banco de dados fica melhor de que forma?

pensei em fazer tipo assim:

database = jogos

tabelas = 1 = need,2 = gta, 3= gtaiv, 4 =call...

dae dentro das tabelas teria milhares de linhas contendo titulo, data, quem postou,tags etc...

digamos q quero ver jogos...

então chamarei em link o nome das tabelas...

escolhi gta;

então chamaria tudo que tem em gta em forma de posts tipo blog...

dae as outras categorias eu criaria igual... exemplo:

database = photoshop

tabelas = 1 = inspiração,2 = brushes, 3= styles, ...

será q fica mais organizado e sem muito pesso na hora de pesquisar? pq dae ja vai dirreto no conteudo oq eu escolher...

não si como q é aki no imasters.. tem bastante conteudo, mas a pesquisa é muuuito lentaa...

seria fazer algo mais rapido...

alguem me explica melhor como q eu faria a fulltext-search na hora de chamar os dados....? vlww

ja quanto a organização do banco, tem forma melhor?? vlwww

::UPDATE::

Na versão 4.0.1, MySQL também pode realizar buscas full-text booleanas usando o modificador IN BOOLEAN MODE.

mysql> SELECT * FROM articles WHERE MATCH (title,body)

-> AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE);

+----+------------------------------+-------------------------------------+

| id | title | body |

+----+------------------------------+-------------------------------------+

| 1 | MySQL Tutorial | DBMS stands for DataBase ... |

| 2 | How To Use MySQL Efficiently | After you went through a ... |

| 3 | Optimizing MySQL | In this tutorial we will show ... |

| 4 | 1001 MySQL Tricks | 1. Never run mysqld as root. 2. ... |

| 6 | MySQL Security | When configured properly, MySQL ... |

+----+------------------------------+-------------------------------------+

então eu poderia mudar para:

mysql> SELECT * FROM articles WHERE MATCH (tags)

-> AGAINST ('palavras aki teste' IN BOOLEAN MODE);

sim, para fazer isso tenho que antes ter criado mais ou menos assim:

mysql> CREATE TABLE articles (

-> id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,

-> tags VARCHAR(200),

-> FULLTEXT (tags)

-> );

usando esse metodo; posso implodir um array com ' ' e jogar ali na pesquisa? ou faço como?

outra dica seria na hora do SELECT * FROM....

Nunca utilize * em consultas: Esta dica é extremamente valiosa, vou explicar por que. Os bancos de dados atuais utilizam um 'banco guias' para gerenciamento dos schemas(bancos de dados), no caso do MySQL todas as informações de databases, tabelas e campos são cadastrados em information_schema, quando você utilizar * o banco internamente precisa verificar no information quais os campos da tabela no qual deseja resultados, caso o SELECT tenha JOIN esse processo é feito para todas as tabelas, isso já diminui a performance, principalmente se o banco for compartilhar, onde deverá haver muitas informações no information_schema. Por isso fica a dica, é melhor declarar todos os campos que deseja retorna, NUNCA UTILIZE *.

seria mais ou menos assim? vlww

Prog · Junho 21, 2012

Bem, vou falar um pouco sobre a minha experiência.

Independente da quantidade de tabelas que o seu sistema possuir, faça toda estrutura modelada da maneira que você achar mais conveniente, os índices serão importantes sim, não deixe de criar.

Falando sobre a busca, você pode ter uma tabela com a seguinte estrutura:

- documentid (integer), url(varchar), dateindex (datetime), author (varchar), keywords (varchar), type (varchar), content (varchar), text (text, com índice full-text)

Muito bem, agora começa a brincadeira. Você pode fazer um processamento em lote, para executar como um agendamento, ou fazer com que a cada novo "documento" cadastrado seja criado um novo registro nessa tabela.

Tá! Mas o que é um documento? Documento é qualquer coisa que você deseja que seja "buscável". E o que vai ter nesta tabela? Todas as informações que ajudem a encontrar este documento. Uma pequena descrição sobre os campos da tabela que eu apresentei (isto é um modelo inicial, pode ser modificado como achar melhor).

- documentid (integer) - um identificador para o seu documento;

- url (varchar) - caminho para a página do resultado;

- indexdate (datetime) - data em que o documento foi criado, para controles de atualização, por exemplo;

- author (varchar) - autor do documento, para exibir na página de resultados;

- keywords (varchar) - palavras-chave, para exibir na página de resultados;

- contenttype (varchar) - tipo do cocumento (ex. HTML, DOC, PDF), para exibir na página de resultados;

- title (varchar) - título do documento, para exibir na página de resultados;

- body (text, com índice full-text) - todo o conteúdo que será buscado.

O campo body é um caso a parte, nele você cadastra TUDO, o título, os textos, as palavras-chave, os autores, as resenhas, os news e tudo mais o que você julgar conveniente para o resultado da busca. É neste campo que você vai rodar a query de pesquisa usando os parâmetros SQL para busca full-text.

De onde vêm as informações de body?

Do seu modelo estruturado.

Mas isto não vai duplicar a informação?

Sim, mas o seu objetivo é otimizar o tempo da resposta. Isto implica em usar mais espaço, além de ter mais controles das informações no momento do cadastro, atualização e exclusão.

E quando o usuário encontrar o que procura, onde ele clica?

Clica no resultado da busca com o link (que esta no campo URL) para a página que vai exibir o que ele esta procurando.

E esses campos da tabela não são pesquisáveis?

Você pode até pesquisar, mas como tudo já esta cadastrado no body, não se faz necessário. Esses campos servirão apenas para exibição.

E esta página abre oq?

Abre um link, exemplos:

http://www.meusite.com.br/resenha.php?id=413

http://www.meusite.com.br/analise.php?id=1099

http://www.meusite.com.br/noticia.php?id=5558

Tem mais coisas para escrever, mas no momento tenho que trabalhar. ;)

Um outro tópico que fala um pouco sobre isto esta aqui, pode ser que lá tenha alguma coisa que você ache pertinente.

http://forum.imasters.com.br/topic/458917-busca-com-zend-search-lucene/

Sander Luís · Junho 21, 2012

Bem, vou falar um pouco sobre a minha experiência.

Independente da quantidade de tabelas que o seu sistema possuir, faça toda estrutura modelada da maneira que você achar mais conveniente, os índices serão importantes sim, não deixe de criar.

Falando sobre a busca, você pode ter uma tabela com a seguinte estrutura:

- documentid (integer), url(varchar), dateindex (datetime), author (varchar), keywords (varchar), type (varchar), content (varchar), text (text, com índice full-text)

Muito bem, agora começa a brincadeira. Você pode fazer um processamento em lote, para executar como um agendamento, ou fazer com que a cada novo "documento" cadastrado seja criado um novo registro nessa tabela.

Tá! Mas o que é um documento? Documento é qualquer coisa que você deseja que seja "buscável". E o que vai ter nesta tabela? Todas as informações que ajudem a encontrar este documento. Uma pequena descrição sobre os campos da tabela que eu apresentei (isto é um modelo inicial, pode ser modificado como achar melhor).

- documentid (integer) - um identificador para o seu documento;

- url (varchar) - caminho para a página do resultado;

- indexdate (datetime) - data em que o documento foi criado, para controles de atualização, por exemplo;

- author (varchar) - autor do documento, para exibir na página de resultados;

- keywords (varchar) - palavras-chave, para exibir na página de resultados;

- contenttype (varchar) - tipo do cocumento (ex. HTML, DOC, PDF), para exibir na página de resultados;

- title (varchar) - título do documento, para exibir na página de resultados;

- body (text, com índice full-text) - todo o conteúdo que será buscado.

O campo body é um caso a parte, nele você cadastra TUDO, o título, os textos, as palavras-chave, os autores, as resenhas, os news e tudo mais o que você julgar conveniente para o resultado da busca. É neste campo que você vai rodar a query de pesquisa usando os parâmetros SQL para busca full-text.

De onde vêm as informações de body?

Do seu modelo estruturado.

Mas isto não vai duplicar a informação?

Sim, mas o seu objetivo é otimizar o tempo da resposta. Isto implica em usar mais espaço, além de ter mais controles das informações no momento do cadastro, atualização e exclusão.

E quando o usuário encontrar o que procura, onde ele clica?

Clica no resultado da busca com o link (que esta no campo URL) para a página que vai exibir o que ele esta procurando.

E esses campos da tabela não são pesquisáveis?

Você pode até pesquisar, mas como tudo já esta cadastrado no body, não se faz necessário. Esses campos servirão apenas para exibição.

E esta página abre oq?

Abre um link, exemplos:

http://www.meusite.com.br/resenha.php?id=413

http://www.meusite.com.br/analise.php?id=1099

http://www.meusite.com.br/noticia.php?id=5558

Tem mais coisas para escrever, mas no momento tenho que trabalhar. ;)

Um outro tópico que fala um pouco sobre isto esta aqui, pode ser que lá tenha alguma coisa que você ache pertinente.

http://forum.imasters.com.br/topic/458917-busca-com-zend-search-lucene/

opaa vlww vou ler com mais tempo sua resposta completinha tbm kkk...

aki vai ser facil para mim, vou usar o htaccess e o php para fazer tipo aki no blog...

tudo oque vem depois de topic/467949-remover-palavras...... deixa só o topic/467949 e prossesa tipo em topico.php?id=467949..

dae vou ter urls amigaveis indexadas, e tbm vai ficar tudo melhor... vou ler com calma oq você me explicou etc ..no mais vlw... era oq eu estava imaginando... e olha q é meu primeiro grande progeto em php e sou novato... tah saindo digamos mais q 100% do esperado... vlw qualquer dicas ae o pessoal e duvidas minha serão postadas aki... obrigado por compartilhar do seu estudo...

UPDATE:

carra entendiiii ok presisava vlwww..

tipo eu crio o post normal, e nessa tabela eu informo digamos o id etc do post criado, na hora da busca vai procurar ae, sem ter q ler todos os posts etc...

resultado 100% mais rapidoo...

e no caso de criar uma paginação? vlw...

digamos e a url seja busca/texto-pra-buscar/2

ate eu consigo com o htaccess mandar para busca/?texto=texto-pra-buscar&pagina=2

dae falta calcular o numero de resultados com o numero q foi encontrado e gerar na pagina os resultado digamos depois de 10... vou ler sobre as paginações etc... vlw

Prog · Junho 21, 2012

A URL pode usar a formatação que você achar melhor para o seu sistema. URLs amigáveis ou encurtadas, a sua vontade.

Sobre a paginação, ocorre conforme qualquer outra paginação PHP + MySQL.

Sander Luís · Junho 25, 2012

A URL pode usar a formatação que você achar melhor para o seu sistema. URLs amigáveis ou encurtadas, a sua vontade.

Sobre a paginação, ocorre conforme qualquer outra paginação PHP + MySQL.

opa blelezaa

viu eu fiz assim por enquanto:

CREATE DATABASE if NOT EXISTS `sandersi_teste`;

USE sandersi_teste;


CREATE TABLE teste(
`id` INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
`area` VARCHAR(100) DEFAULT NULL,
`post_id` VARCHAR(100) DEFAULT NULL,
`titulo` VARCHAR(100) DEFAULT NULL,
`busca` TEXT,
FULLTEXT (`titulo`,`busca`)
)  ENGINE=MyISAM;

INSERT INTO `teste`(`id`,`area`,`post_id`,`titulo`,`busca`) VALUES (NULL,'photoshop','1','Desenhando Uma Ferrari - Tutorial','ferrari desenho tutorial desenhando teste');

INSERT INTO `teste`(`id`,`area`,`post_id`,`titulo`,`busca`) VALUES (NULL,'gta_sa','1','Como Instalar Carros - Tutorial','instalar carros como tutorial');

INSERT INTO `teste`(`id`,`area`,`post_id`,`titulo`,`busca`) VALUES (NULL,'photoshop','1','Desenhando Um fusca - Tutorial','fusca desenho tutorial desenhando teste');

INSERT INTO `teste`(`id`,`area`,`post_id`,`titulo`,`busca`) VALUES (NULL,'photoshop','1','Olha o fusca','filme completo olha fusca');

e para buscar fiz assim

SELECT * FROM `teste` WHERE MATCH (titulo,busca) AGAINST ('"teste" "fusca"' IN BOOLEAN MODE);

funcionou perfeitoo

mas dae me preocupei quanto aso "" ali separando as palavras da busca... dae inventei de testar assim:

SELECT * FROM `teste` WHERE MATCH (titulo,busca) AGAINST ('teste fusca ferrari' IN BOOLEAN MODE);

resultado... perfeito o dito "desenho" q antes não dava resultado respondeu com

Showing rows 0 - 1 ( 2 total, Query took 0.0002 sec)

agora para buscar e mostrar primeiro os ultimos posts eu add no final ORDER BY `id` DESC;

então:

SELECT * FROM `teste` WHERE MATCH (titulo,busca) AGAINST ('teste fusca' IN BOOLEAN MODE) ORDER BY `id` DESC;

resultou em:

Showing rows 0 - 3 ( 4 total, Query took 0.0086 sec) [id: 5 - 1]

me ajuda ae dando umas dicas no que pode mudar etc pra ficar melhor e mais rapido pq depois vai ter muitttos dados ae dae vai ter q agilizar kkk..

agora veja se esta bom a ideia ou vai ficar muito lento...

note que ali nos resultados eu tenho o post_id e a area...

então tendo buscado, encontrado os resultados, eu vou fazer uma nova busca pegando somente os posts do post_id, dentro da tabela "area" q será outra... e imprimir na tela... seria mai ou menos isso ou tem outro geito de ja imprimir o post atravez do post_id q ja tem ae:? vlww

Prog · Junho 25, 2012

Não entendi muito bem sua questão.

Não se faz necessário fazer 2 buscas, pq esta pensando desta maneira?

Sander Luís · Junho 25, 2012

Não entendi muito bem sua questão.

Não se faz necessário fazer 2 buscas, pq esta pensando desta maneira?

assim, eu estava pensando de pegar o id e a area na busca somente isso.. dae depois buscar novamente por * na area pelo id do post dae ja imprimiria ele inteiro com tudos os dados,

eu não quero por o link para a postagem, querer ate posso, mas ja quero imprimir o post completo... seria nescesario fazer 2 buscas, uma retorna os id dos posts em sua rea e a proxima pega tudo dos ids encontrados e imprime

seria igual o blogspot...

imprime todo o post e tbm tem o link só para o post dae com os comentarios etc... entende?? vlww

tem algo melhor?? vlw

Prog · Junho 25, 2012

Sim, acho que seu entendimento esta correto.

Você tem uma página de resultados, que faz uma consulta na tabela que tem o indice full-text.

Quando você clica no link, você vai abrir a página correspondente ao resultado da busca. que pode ser uma outra página PHP (com ou sem consultas SQL).

"Igual" o google.

Sander Luís · Junho 26, 2012

Sim, acho que seu entendimento esta correto.

Você tem uma página de resultados, que faz uma consulta na tabela que tem o indice full-text.

Quando você clica no link, você vai abrir a página correspondente ao resultado da busca. que pode ser uma outra página PHP (com ou sem consultas SQL).

"Igual" o google.

isso.. só q em vez se mostrar apenas o link, ja mostra o post completo...

tipo busco "ferrari teste"

vai me retornar o id do post e a area do post do que foi pesquisado.... isso na tabela que tem o indice full-text...

tendo a area, e o id do post então faço uma nova busca pegando o post completo, pelo seu id na area corespondente...

essa area será o nome da tabela dentro do banco posts...

entendes?

tudo será separado...

exemplo:

buscar "texto teste" Em: "photoshop"

loga em busca, na tabela photoshop, e procura pelo "texto teste" dentro de titulo|busca (ae q tah a referencia do ful-text)

veja o esquema:

banco: busca
  tabela:photoshop
       id|area|post_id|titulo|busca
  tabela:dreamweaver
       id|area|post_id|titulo|busca
  tabela:gta
       id|area|post_id|titulo|busca

digamos q voltou como resultado:

id|area|post_id|titulo|busca

4|gta|2|Olha o fusca|gta sa teste carros ferrari

então, oq achei ali q interessa é area e post_id....

como ali a area foi gta e o post_id foi 2,

logo em posts, na tabela "gta" e seleciono * para o id 2

banco: posts
  tabela:photoshop
       id|titulo|data|like|autor|tags|body
  tabela:dreamweaver
       id|titulo|data|like|autor|tags|body
  tabela:gta
       id|titulo|data|like|autor|tags|body

resultado:

Olha o fusca

-------------------

data: xx/xx/xx

likes: x

autor: xxxxxx

------------------------------

texto akie fsdf 35468745

------------------------------

tags: tags aki...

tava pensando em colocar tbm os comentarios... mas logo mais..

tenho a possibilidade de criar quantos bancos quiser etc e trafego tudo ilimitado...

então acho q desse geito vai ficar mais rapido a busca... primeiro qvai estar tudo em categorias diferentes, mesmo que tenha bastante conteudo, o filtro da busca ja vai dirreto para a tabela q tem o contudo e ja pega pelo post correto... acho q vai ficar rapido...

DIGOO: SOU INICIANTE, PRETENDO APRENDER BEMM, MAS PELO PROGETO Q ESTOU FAZENDO ACHO Q DESSE GEITO VAISER MELHOR...

MAS TBM PRECISO DA AJUDA DE QUEM ENTENDE... ENTÃO PEÇO PARA DAR UMA VERIFICADA NO QUE POSTEI< PARA VER SE TEM ALGUM METODO MELHOR... SE TIVER DIGA-ME, POIS O PROGETO ESTA APENAS NO PAPEL E NÃO ONLINE, HA TEMPO DE MUDAR TUDOO SE PRESISO...

sabe ali na hora de pegar o post pelo id?? como q eu faço digamos para pegar 10 posts pelos respectivos ids...

UPDATE:

$galleries = array
        (
          [0] => 1
          [1] => 2
          [2] => 5
        );
$ids = implode(',', $galleries);  
$sql = "SELECT * FROM gta_sa WHERE id IN ($ids)";

achei isso, dae todos os post_id q resultar colocarei no array, guardarei a "area" e mando o select... parece funcionar bem..

Prog · Junho 26, 2012

Se você quer velocidade e recursos otimizados sua página de resultados deve exibir apenas as informações mais relevantes com o que já tem na tabela de busca.

Isto pode ser customizado com tempo e ajustado de uma maneira a atender melhor as suas necessidades. Eu diria ser bem difícil chegar a uma conclusão dessas no início do projeto, então, use uma fórmula já consagrada no começo e vá melhorando com o tempo.

Sander Luís · Junho 27, 2012

Se você quer velocidade e recursos otimizados sua página de resultados deve exibir apenas as informações mais relevantes com o que já tem na tabela de busca.

Isto pode ser customizado com tempo e ajustado de uma maneira a atender melhor as suas necessidades. Eu diria ser bem difícil chegar a uma conclusão dessas no início do projeto, então, use uma fórmula já consagrada no começo e vá melhorando com o tempo.

blzzz vlww

[RESOLVIDO]

Arquivado

[Resolvido] busca fulltext search e organização do db - tipo blog

Recommended Posts

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Prog 183

Compartilhar este post

Link para o post

Compartilhar em outros sites

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Prog 183

Compartilhar este post

Link para o post

Compartilhar em outros sites

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Prog 183

Compartilhar este post

Link para o post

Compartilhar em outros sites

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Prog 183

Compartilhar este post

Link para o post

Compartilhar em outros sites

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Prog 183

Compartilhar este post

Link para o post

Compartilhar em outros sites

Sander Luís 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Conexão mysql com outro domínio

[Resolvido] JavaScript - Exibir logo dentro da Tabela html

Javascript - Calcular Valores Monetário em Tempo Real

Fóruns

Tempo Real

Informação importante