Bases de dados

É muito frequente encontrar programadores que olham para as bases de dados como repositórios de informação de acesso supostamente rápido.

E a coisa lá vai funcionando….bom, também com um catalogozito com 500 produtos, até um ficheiro .txt aguentava com tamanho processamento de dados.

Mas na verdade, quando se fazem meia dúzia de perguntas, fica-se logo a perceber se um programador sabe realmente o que é uma base de dados e se tira ou não partido das suas capacidades.

Costumo fazer o seguinte exercício para obter a melhor abordagem num determinado caso
Dimensionar a utilização da informação

É muito importante analisar de que forma um sistema vai disponibilizar a informação.

Por exemplo, num site, é bem mais comum podermos ter centenas de pedidos simultâneos de consultas e poucas actualizações, visto que um site é administrado por um conjunto restrito de utilizadores e consultado por dezenas ou centenas.

Por esta lógica, é prioritário acelerar as consultas em deterimento das instruções nobres de actualização de informação

Costumo perguntar para que serve um índice numa tabela. A resposta normalmente vai no sentido de melhorar as consultas de informação. Logo de seguida questiono porque razão então não colocamos toda a informação índexável, porque se o objectivo é melhorar, então coloca-se tudo como índice!!! Normalmente o bom senso não o permite e ainda bem, mas também a resposta não é evidente.

Por isso costumo levantar este problema. Porque como em tudo o bom senso deve prevalecer e neste caso também, é importante indexar as formas de aceder aos dados mas, levando sempre em conta a utilização que vai ser dada e questionando sempre o impacto que estes índices terão nas instruções de actualização.
Levar sempre em conta a prioridade dos dados

As instruções de INSERT, UPDATE e DELETE, são muito pesadas por natureza, porque além de mexerem com o repositório de informação também obrigam a recontrução de índices, o que pode tornar-se pesado. Como a maior parte das bases de dados utilizam sistemas de QUEUE para irem “servindo” os pedidos, estas operações podem em determinadas situações ser consideradas de baixa prioridade, dando assim espaço a serem processadas em tempos mortos.
Pensar nos queries como se fosse uma folha de excel

O exercício é simples, basta pensar que temos que visualmente procurar informação e que dispomos de uma folha de cálculo. se existir ordenação posso sempre começar por ordenar pela coluna que mais facilmente me permite obter o menor número de resultados e depois se não tiver mais critérios, então visualmente vou correr linha a linha de forma a verificar quais as linhas que satisfazem o meu critério.

Portanto, como muitos motores de bases de dados utilizam os critérios WHERE pela prioridade descritiva, convém colocar estes critérios numa ordem pensada.

Caso prático:
– obter todos os clientes com nome=”paulo” e com sexo=”M”
tabela :

id (numeric)
nome (string)
sexo (char)

Na minha análise, não existindo uma chave composta, o critério utilizado pelo motor de bases de dados é a ordem dos filtros, então irá existir uma diferença considerável entre:

select * clientes where nome=”paulo” and sexo=”M”
select * clientes where sexo=”M” and nome=”paulo”

(1) a utilização de “select *” não sendo uma boa prática dava jeito por questões de design
Voltando ao caso…..penso que existirão menos clientes com nome=”paulo” que sexo=”M”. Em circunstâncias normais, o campo sexo devolveria metade dos registos e posteriormente teria que fazer uma verificação linha a linha. No caso do nome, devolveria uma parte garantidamente menor, reduzindo assim o segundo passo.

Alguns motores de bases de dados já o fazem automaticamente, mas um bom princípio não deixa de ser um bom princípio. Quanto mais percebermos ou tentarmos perceber como funciona uma base de dados, mas fácil e intuitivo é tirar proveito de um sistema.

Deixar uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *