O MySQL é muito rápido no acesso aos dados mas o que acontece quando os aplicativos vão acumulando grandes quantidades de registros? Estou desenvolvendo um aplicativo empresarial com fins didáticos e, apesar de quase pronto, até agora não fiz uso de nenhum índice. Nos meus tempos de programador Clipper só se trabalhava com índices, precisava de índices para tudo a opção era uma lentidão sem tamanho.
Pergunto aos gujeanos (usuários do GUJ) o que acontece em um aplicativo Java quando o banco de dados vai crescendo? Os acessos vão se tornando proibitivamente lentos? Há a necessidade de utilizar os índices através do INDEX? Pergunto porque é um aspecto prático no desenvolvimento de aplicativos considerar o uso de índices.
Sim, índices são necessários para melhorar a performance e trazer organizado os dados.
Sistemas sem indices, somente se for muito pequeno o banco de dados de tal forma que possa colocar inteiro na memoria, mas mesmo asssim indices são recomendados.
E conforme vai crescendo a tabela, se ela esta indexada os indices crescem tambem, igualzinho ao finado Clipper.
Alias o Clipper tambem usava BTree e os bancos de dados oferecem as mesmas implementações dos mesmos algoritimos,mas normalmente B+Tree sempre está presente.É muito bom viu, com ele dá pra obter qualquer registros em uma tabela de 1 milhão por exemplo com menos de 10 leituras no disco.
O driver JDBC não degrada tanto assim o retorno do banco de dados, é satisfatório.
E tambem lembre-se quando o retorno for muito grande, pensa em paginar ele na query.
Sim, mas tem bancos embutidos que possibilitam chamar diretamente os dados sem o Select. No entando depois de criado o indice no banco, internamente é o motor do banco quem cuida disso e não a sua aplicação.
Basta apenas abrir normalmente o banco de dados, porque uma vez criados os indices ele
se vira por manter atualizado e vinculado.
Corrupção pode sempre acontecer quando um arquivo está aberto e acaba a energia, ou o computador travar com o tal do espetacular Windows trava trava, isso pode levar a corromper os indice(s) ou até mesmo a(s) tabela(s). Mas com a evolução dos bancos de dados, ao iniciar o motor dele, percebendo essa anomalia o corrige automaticamente, e se isso não acontecer através da manutenção pode forçar a correção manualmente, nesse caso precisa ver a documentação.
Mas de uma forma geral, são feitos para garantir a integridade dos dados, independentemente da sua aplicação, por isso são tão populares e seguros.
Mas aquela coisa do Clipper que de vez e sempre os arquivos ficavam corrompidos, esqueça, em banco de dados isso é uma exceção que quase nunca você irá se deparar.
Acabei de olhar aqui num armário e ainda tenho os livros:
dBase III Plus Interativo, 4ª Edição do João Alexandre Magri e
Clipper 5, Release 5.2, Volume 1 do José Antônio Ramalho
Ainda lembro dos índices .ndx do dBase e .ntx do Clipper, que ficavam desatualizados se não fossem abertos juntos na hora do comando USE e que corrompiam com bastante facilidade e não sinto nenhuma falta disso.
SQL, apesar de ser até mais antigo que o dbf parece muito mais moderno, stored procedures, triggers, views, relacionamento entre tabelas e atomicidade, foram coisas com as quais nunca nem sonhei em minha época de adolescente espinhento.
Agora um comentário meio off-topic.
As pessoas imaginam que nossa obsessão por TI é porque gostamos de tecnologia, mas na verdade nossa obsessão é por desafios. Somos vampiros que se alimentam de desafios e os desafios nos mantém jovens, vimos jogadores de futebol, pilotos de fórmula 1 e outros ídolos sucumbirem diante dos mais jovens, mas nós, apesar dos altos e baixos, aqui estamos, tão jovens quanto há 30, 40 ou 50 anos. E os mesmos desafios que fazem fracassados desistirem, nos fazem acordar e levantar da cama todo dia pra viver.
Eu tenho os dois volumes dbase 3 plus interativo e programável, acho que são do mesmo autor que o seu. Na época eram excelentes. Foi assim que aprendi programar em 1991.