Pesquisa de desktop do Windows - SQL inacreditável lenta '%Search%'
Pergunta
Estou tentando consultar a API de pesquisa de desktop do Windows usando o SQL.
Devo dizer que realmente odeio a GUI da Windows 7 e, por isso, decidi escrever o meu. Eu tenho muitos arquivos indexados (aproximadamente 1.000.000) e quero fazer uma pesquisa por nomes. Algo como: Mostre -me todo nome que contém "Bunny".
Mas aqui eu encontro um problema de desempenho. Procurando por
SELECT "System.ItemPathDisplay"
FROM "SystemIndex"
WHERE System.FileName LIKE 'egon%'
é muito rápido. Também o %egon
alternativo. Mas %egon%
leva uma eternidade. Não tenho certeza se está na natureza do índice (entendo que as possibilidades aumentam enormemente) ou se estou fazendo algo errado.
A questão é:
- É correto que o índice do Windows seja apenas um grande banco de dados SQL?
- Nesse caso, onde posso encontrar informações exatas sobre a estrutura do banco de dados (chaves primárias, índices).
Se eu tiver isso, basicamente está apenas otimizando o SQL.
Pergunta alternativa: Alguém conhece uma instrução SQL rápida para encontrar todos os arquivos com Egon em algum lugar no nome.
EDIT: Por que eu não gosto da GUI de pesquisa
Bem, simplesmente não é intuitivo, em comparação com o XP. Se você desativar o cachorro e usar a interface XP antiga, eu poderia criar uma consulta de pesquisa como:
- Todos os arquivos com mais de 1 mês
- maior que 10 MB
- Nome Pattern
*_homework_*.docx
Experimente isso no Windows 7 sem "aprender" a sintaxe. E inferno eu faço não Deseja aprender outra sintaxe apenas para encontrar um arquivo.
O outro principal problema são talvez meus hábitos de pesquisa. Na maioria das vezes, de alguma forma conheço o nome do arquivo (ou partes) e simplesmente quero o local. E se você usar a pesquisa desta maneira, terá vários problemas:
- Primeiro de tudo, você sempre precisa prefixá -lo com o nome:
- Então o layout do nome da pasta é estúpido (está pedindo pela pasta pai, não caminho completo, eu acho, porque .. tada ... veja o próximo ponto)
- Então, ainda mais irritante, se você tiver uma lista de resultados e tenta classificá -los, leva uma eternidade
E agora eu realmente acho que meu sistema tem um bug. Tentei verificá -lo rapidamente, pesquisado em uma pasta de tamanho médio para "teste" e ele encontrou alguns arquivos. Então eu tentei classificá -los para pastas (para verificar meu segundo ponto) e agora ele está apenas pesquisando para sempre ... quero dizer, realmente, enquanto estou digitando ele tenta encontrar a palavra "olá" ... Oh, terminado - ele encontrou aproximadamente 20 arquivos. Então, agora, vamos tentar algo ... ok, agora parece que ele se recuperou .. mas ainda assim, para desacelerar para o meu gosto ...
Então, o suficiente xingar sobre a pesquisa :-)
Solução
Parece que eles estão criando um índice no nome, para que ele possa usar o índice, desde que você especifique o início da string, mas se você não tiver, ele precisa usar uma varredura de tabela.
Supondo que estejam usando o mecanismo de pesquisa de texto completo da Microsoft e tente usar algo como:
... onde o System.FileName contém 'egon'
Existem basicamente duas opções: será rejeitado como inválido (ou seja, essa interface SQL não suporta sua extensão de pesquisa de FT) ou então será um pouco mais rápido.
EDIT: OOPS - A sintaxe deve ser "contém (System.FileName, 'Egon')". Desculpa aí.
Outras dicas
Talvez tente
"SELECT \"System.ItemPathDisplay\" FROM \"SystemIndex\" WHERE CONTAINS(System.FileName, 'egon')";
Isso é lento porque você não pode usar um índice. O motivo é que você está procurando uma partida em um lugar na string, e não no início da string, o que significa que você deve digitalizar a tabela inteira para o conteúdo.