Um sistema que trabalha registro por registro pede para procurar um produto e avançar para o seguinte, enquanto o MySQL só entende consultas SQL. Entre os dois, uma camada da aplicação converte cada operação de navegação em consultas. Quando um dado existe no banco, mas a tela mostra um resultado inesperado, a explicação costuma estar no SQL que essa camada montou.
Onde a camada funciona
A camada de tradução faz parte da aplicação e roda na estação, junto com as telas. Ela não é um serviço instalado no servidor do MySQL. No mapa das quatro camadas do acesso aos dados, ela ocupa o lugar da camada de acesso a dados.
Em sistemas que nasceram em bancos de dados em arquivos, essa camada costuma ser substituível. As telas pedem as operações à camada, e não ao armazenamento, e por isso o mesmo código das telas pode trabalhar com os arquivos ou com o banco SQL, conforme a camada instalada.
Da navegação ao SQL
Cada operação de navegação vira uma consulta com uma condição, uma ordem e um limite de linhas. Na tabela produtos, a coluna id faz o papel de número do registro e serve de desempate. Na ordem de código, as formas básicas são parecidas com estas:
SELECT * FROM produtos ORDER BY codigo, id LIMIT 20;: vai ao início da ordem;SELECT * FROM produtos WHERE codigo >= '7891234567890' ORDER BY codigo, id LIMIT 20;: posiciona no código procurado;SELECT * FROM produtos WHERE codigo > '7891234567890' OR (codigo = '7891234567890' AND id > 315) ORDER BY codigo, id LIMIT 20;: avança a partir do registro atual, que tem o código 7891234567890 e o identificador 315;SELECT * FROM produtos ORDER BY codigo DESC, id DESC LIMIT 20;: vai ao fim da ordem.
O recuo usa a mesma forma do avanço, com as comparações invertidas e a ordem decrescente.
Na busca, a camada confere se a primeira linha devolvida tem o código procurado. Se não tiver, o código não existe, e a posição fica no código seguinte ou no fim da ordem, conforme a opção da busca. No avanço, a condição com OR traz os códigos maiores que o atual e, dentro do mesmo código, os identificadores maiores que o do registro atual. Assim, os produtos com o mesmo código não são pulados nem repetidos.
A forma exata do SQL depende da camada, da versão e da configuração. Esses exemplos mostram o mecanismo, e o SQL real fica no registro da própria camada.
As condições que a camada acrescenta
O SQL enviado costuma ter condições que não aparecem na tela:
- Marca de exclusão: quando a camada está configurada para esconder as linhas excluídas logicamente, a condição da marca entra em todas as consultas, como
(excluido IS NULL OR excluido <> 'S'). - Condição da ordem: uma ordem pode ter uma condição própria, que limita as linhas que pertencem a ela, como uma ordem só com os produtos ativos. Nessa ordem, um produto inativo não aparece na navegação, embora continue na tabela.
- Filtro da tela: uma tela pode limitar a navegação a um período, a um caixa ou a uma situação.
Por isso, um registro presente no banco pode ficar fora da navegação sem nenhum defeito nas tabelas.
A leitura em lotes
A camada não precisa enviar uma consulta a cada avanço. Ela costuma buscar várias linhas de uma vez, guardá-las na memória da estação e atender os próximos avanços com as linhas já recebidas. Quando o lote acaba, a camada envia uma nova consulta a partir da última linha lida.
As linhas guardadas na memória refletem o banco no momento da leitura. Uma alteração feita por outra estação aparece quando a camada lê o banco de novo, por exemplo ao reabrir a tela ou ao repetir a busca.
Os elementos que a camada mantém no banco
Para reproduzir o modelo de acesso por registro, a camada cria e mantém alguns elementos no banco:
- colunas de controle, como o número de cada registro e a marca de exclusão;
- colunas calculadas para as ordens que o banco não monta sozinho;
- índices no MySQL que correspondem às ordens da aplicação;
- uma tabela de controle que descreve as ordens de cada tabela, com a expressão, a condição e o nome do índice correspondente.
Para o MySQL, essas colunas e tabelas são comuns. O MySQL não conhece o significado delas, e um comando feito direto no banco não segue as regras que a camada aplica.
O registro de SQL
Muitas camadas de tradução conseguem gravar em arquivo o SQL enviado ao servidor e as respostas recebidas. Esse registro mostra as condições, a ordem e os limites reais de cada operação, e é a evidência mais direta para separar um dado ausente de uma consulta que não o incluiu. Como o registro aumenta o trabalho da estação e o tamanho dos arquivos, ele costuma ficar desligado e ser ligado apenas durante uma investigação.
No suporte
Quando a busca do sistema se comporta de forma inesperada, convém examinar o SQL realmente enviado pela camada, com as condições, a ordem e o limite. Um dado presente no banco e ausente na tela costuma estar fora de alguma condição acrescentada pela camada, como a marca de exclusão ou a condição da ordem.
Para guardar
- A camada de tradução roda na estação, dentro da aplicação, e converte a navegação em consultas SQL.
- Cada operação vira uma consulta com condição, ordem e limite, e o identificador desempata os valores repetidos.
- A camada acrescenta condições que não aparecem na tela, como a marca de exclusão e a condição da ordem.
- A leitura em lotes faz com que nem todo avanço gere uma consulta nova.
- O registro de SQL da camada mostra as consultas reais.
Cada avanço de registro na tela envia uma consulta nova ao MySQL?
Não necessariamente. A camada pode buscar várias linhas de uma vez e atender os próximos avanços com as linhas já guardadas na memória da estação. Uma consulta nova sai quando o lote acaba, e o registro de SQL mostra quando isso aconteceu.
Um produto existe na tabela, mas não aparece quando a lista do sistema é percorrida na ordem de descrição. O que examinar?
O SQL que a camada enviou para essa ordem. A linha pode estar marcada como excluída, fora da condição própria da ordem ou fora de um filtro da tela. Nesses casos, o comportamento segue as regras da aplicação e não indica defeito no banco.