A técnica que vou ensinar neste post - e é uma das mais recentes utilizadas em nossos sistemas, embora não seja nenhuma novidade - chama-se "query simulada".
Mas antes vou falar sobre um filme que assisti há alguns anos atrás, chamado "Lances Inocentes" (Searching for Bobby Fischer).
O filme conta a história de um garoto que tem um talento especial para o xadrez e é incentivado pelo pai a participar de competições. A família do menino contrata um instrutor que passa a treiná-lo sob uma abordagem clássica do xadrez. Só que simultaneamente, o garoto conhece um enxadrista de rua, que também o influencia, mas sob a ótica do "speed chess", com técnicas bastante heterodoxas, consideradas pelo instrutor do menino como de segunda categoria. E instala-se o conflito.
Mas o que, afinal, tem a ver o xadrez de rua com sistemas rápidos?
Bem, no contexto de sistemas, sempre existiu uma discussão sobre boas práticas de programação. Há um conflito entre o meio acadêmico e quem "põe a mão na massa".
Nesse contexto, todos sabemos que colocar informações hard-coded no sistema (junto com o código-fonte) é uma prática péssima de programação, certo?
Bem, o enxadrista de rua do filme tinha seu ponto de vista. E sua técnica funcionava em determinadas ocasiões. E ajudou o menino a encontrar um meio termo.
Portanto, estou dizendo que tudo na vida depende do contexto. Em uma situação em que a velocidade de resposta é condição sine qua non, aceito sim ser um pouco heterodoxo.
Isto posto, vamos ao que interessa: O que afinal é uma "query simulada"?
De forma simples, é programar o resultado de uma query hard-coded no sistema. Posso dizer que é uma espécie "query cacheada" que não expira e que ocupa a memória pontualmente, por pouco tempo. A vantagem não podia ser outra: Velocidade, disponibilidade, menor probabilidade de falhas.
Fazemos isso pegando um método que retorna uma query real, indo efetivamente ao banco de dados, substituindo-a por uma query simulada. Para o resto do sistema, é como se estivéssemos indo realmente ao banco de dados. O retorno continua sendo um recordset, mas nós o preenchemos manualmente e o sistema é induzido a acreditar que os dados vieram mesmo do banco. E não tem mesmo diferença nenhuma.
Essa foi uma forma de otimizarmos ainda mais o que já havia sido otimizado em nossos sistemas.
Estudamos as queries elegíveis para "query simulada" e as convertemos, é claro, com muito critério.
Como exemplo, imagine uma query que vai ao banco de dados obter os estados federativos brasileiros e que é muito utilizada. É possível criar uma query fake no sistema que contenha a lista dos estados. O acesso é infinitamente mais rápido do que indo ao banco. Evita tráfego de rede, vai continuar mostrando os estados mesmo que o banco esteja fora do ar, enfim, no contexto de um sistema que não pode ter gargalos, é uma técnica a mais no rol das possibilidades., e que não deve ser ignorada.
Fique ligado que ainda tem muito mais pela frente! Até o próximo post.
Nenhum comentário:
Postar um comentário