**Atenção: Este post contém um pensamento sem solução. Talvez você ache algo aqui que lhe ajude, mas a idéia principal
do texto abaixo é apenas mapear um questionamento que ainda não solucionei. Portanto, leia por sua conta e risco.
Se você tiver algo para contribuir, desde indicar partes que não ficaram claras até responder todas as dúvidas contidas
aqui, superficial ou aprofundadamente, fique a vontade para usar os comentários.**
Estava eu aqui filosofando um pouco sobre banco de dados, repassando os últimos acontecimentos que me proporcionaram algum
aprendizado sobre SQL e pensei no seguinte:
Digamos que exista uma tabela com os campos `config, value, usr`.
Dessa forma se forem feitas pesquisas do seguinte estilo:
SELECT usr
FROM tabela
WHERE (config = ‘a’ AND value > 34)
AND (config = ‘b’ AND value < 48)
OR (config = ‘d’ AND value between 10 AND 30)
AND (config = ‘c’ AND value = 53)
OR (config = ‘e’ AND value != 30)
…..
É verdade que, no caso específico desse tipo de consulta, gerar índices para `config` e `value` é algo que faz sentido
no que diz respeito a otimização?
Seria algo como não precisar varrer a tabela inteira na hora de pesquisar os caras que tem `config` ‘a’,'b’,e/ou ‘c’
e assim por diante, não?
Afinal, os índices podem ser vistos como a mesma tabela,
ordenada pelo campo em questão; desse modo é possível, ao menos, fazer busca binária; certo ?
Isso facilitaria na hora de separar os conjuntos para depois fazer a interseção.
Mas talvez isso só valha realmente apena, ou mostre-se menos trabalhoso do que a própria consulta,
apenas para um dado número `config * user`.
Isso para poder calcular a complexidade do trabalho.
Na prática, se tivermos o seguinte:
select avg(value), max(value), min(value), stddev(value)
from (select count(*) value, usr
from formcidadesum_answers
group by usr
) as value
+————+————+————+—————+
| avg(value) | max(value) | min(value) | stddev(value) |
+————+————+————+—————+
| 10.3687 | 17 | 9 | 1.6727 |
+————+————+————+—————+
Ou seja:
uma média de 10 `config` por `usr` (lembrando que cada a cardinalidade entre `usr` e `config` config é
[m, n] / 0 <= m <= count(usr) && 0 <= m <= count(config)
Teremos, então, no caso da tabela acima, com 6000 usr, a tabela proposta no início teria cerca de 62200 registros.
Ou seja, cada índice teria que ordenar 62200 registros.
Será que, para essa quantidade, o trabalho gasto para indexação já é superado pela economia nesse tipo de consulta?
