Minimizando desastres ao Acesso a Banco de Dados

Assuntos Gerais
#1

Olá camaradas!!!

Manter a integridade de um Banco de Dados é, para mim, uma tarefa muito séria. Principalmente quando o repositório é acessado inúmeras vezes e com múltiplos acessos.
Sabemos que os SGB´s hoje estão muito robustos, e até mesmo os SGB´s “open”.
Os desastres costumam acontecer geralmente quando o BD está “aberto” para uma consulta(QUERY).
Desta forma vislumbro que quanto menor o tempo em que o BD estiver aberto menor a possibilidade de se expor o repositório a falhas.
Eu costumo “construir” o acesso aos dados da seguinte forma:
Vamos supor que eu tenha que navegar em uma tabela do meu Bando de Dados TabelaAlunos.

  • Abro a conexão e faço o primeiro acesso;

  • Passo um parâmetro SQL tipo “SELECT * FROM TabelaAlunos;”

  • Dentro do loop do ResultSet (next) copio todo o conteúdo do Banco de Dados da seguinte forma:

      - Crio um objeto "aluno" (new) e copio todo o conteúdo do primeiro registro do BD para dentro deste objeto;
  - De posse de um List recém criado, copio o objeto "aluno" (que é uma cópia fiel do registro do BD) para dentro do List;
  - ...e desta forma faço esta operação até o final do ResultSet.next adicionando novos objetos "aluno".

  • Fecho a conexão;

  • Depois disto crio meus métodos de navegação no List…e pronto.

…desta forma terei um List de objetos para navegar no sistema.
Meu Banco de Dados estará fechado e diminuirei muito a taxa de desastres no mesmo.

Bem !!

Digamos que a “navegação” no meu List de objetos pode se tornar pesada e lenta demais se eu tiver muitos(dezenas de milhares) de objetos…

Bem. Desta forma o que eu faço é dividir em grupos de registros de dados que serão copiados para o List de objetos “aluno”.
Se durante a navegação(ou uma busca por um registro-objeto) meu sistema verificar que ele não está naquela grupo de objetos “aluno”, volto a repetir a operação à partir do último objeto lido no List. …e carrego novamente outro grupo.
Esta operação se sucederá até o momento em que o objeto que procuro seja encontrado ou não exista.

Esta operação será realizada para qualquer evento que necessite consultar dados do BD.

Eu ví várias opções tanto aqui quanto em outro grupos/forúns sobre navegação nos registros do Banco de Dados.
Alguns até interessantes, mas na maioria das vezes o foco era a navegação. O que tem que ser orientado é que não deixemos de executar o meuBandoDeDados.CLOSE.

Eu costumo usar muito o “mundo open source”. IDE NetBeans, Java, FireBird ou MySQL, StarUML etc e tal.

O que vocês acham desta metodologia?
Existe coisa mais eficiente??

Abraços…

#2

Isso não é só uma boa prática, mas, também é quase um mantra.
Não apenas pela exposição dos dados, mas, por performance. Realizar uma busca que traga 1 milhão de registros, instanciar 1 milhão de objetos e guardá-los em memória é das coisas menos performáticas que existem.
Não entendi a relação entre isso e o uso de ferramentas open source. Tanto o MySQL, quanto o Postgres possuem meios para delimitar o número total de registros retornados em uma consulta. Oracle e SQL Server idem. Qual a neura nisso?
Eclipse não é open source, engraçado, nunca me cobraram nada por usá-la…
Enfim, não sei qual a razão.
Desastres associados a bancos de dados até podem ser causados por erros na abertura/fechamento da conexão, mas, em sua maioria, está na construção incorreta de schemas e tabelas, nos grants mal concedidos a usuários e à falta de políticas de segurança de acesso.
Se um schema possui tabelas sem normalização, a probabilidade de inconsistência de dados é altíssima. Ter dados ruins é pior que não ter dados.
Se um usuário tem permissões indevidas, ele poderá fazer coisas indevidas.
Se não há trilha de auditoria, não há garantias de que tudo o que está no banco deveria estar ali e, pior, não há como garantir que o que foi colocado lá realmente continua lá.
Outro porém independe do tempo em que uma conexão fica ativa: SQL Injection. De nada adianta tua conexão ficar aberta por 15 ms se neste intervalo de tempo um SQL Injection for executado…

#3