Certo, sabemos que o SQLite muitas coisas legais, conforme pode ser visto
aqui, que é bom para isso e aquilo e que é fácil de portar e não sei o que. Mas então, quando não usá-lo?
- Altas taxas de transação - O SQLite é capaz de suportar taxas moderadas de transações, mas ele é incapaz de dar acesso simultâneo a um registro. A concorrência do SQLite depende de bloqueios de arquivos para que a base fique protegida contra perda de dados. Assim é possível permitir a leitura desta base de dados para muitos cliente, mas esta base de dados estará bloqueado para qualquer tipo de escrita. Isso acarreta na serialização das operações de escrita. O que acaba por limitar a taxa de transação global da mesma.
- Base de dados muito grandes - É possível escalar arquivos de banco de dados de 2TB no SQLite, mas há custos de memória (RAM) associados a grandes bases. Uma base de dados de 100GB exigiria a alocação 25MB de RAM antes de cada transação, isso aumentaria de forma linear conforme a base de dados cresce. Outro ponto importante de se informar é que a base de dados do SQLite é apenas um arquivo. Consequentemente esse tamanho da base de dados estará ligado ao tamanho máximo que o sistema de arquivos do sistema operacional consegue armazenar. Em um sistema FAT o máximo seria de 4GB.
- Controle de Acesso - SQLite não tem dados de autenticação e autorização. Em vez disso, SQLite depende das permissões do sistema de arquivos para controlar o acesso ao arquivo de banco de dados em bruto. Isto essencialmente limita o acesso a um dos três estados: completar acesso leitura / gravação, acesso somente leitura, ou nenhum acesso. O acesso de escrita é absoluta, e permite que tanto a modificação de dados e a capacidade para alterar a estrutura da base de dados propriamente dito.
Embora a API SQLite fornece um mecanismo de autorização de base da camada de aplicação, é trivial para contornar se o usuário tem acesso direto para o arquivo de banco de dados. Em geral, isso torna SQLite inadequado para lojas de dados sensíveis que requerem por usuário controle de acesso.
- Cliente / Servidor - Como foi projetado para ser embarcado junto com a aplicação, ele não possui internamente um componente de rede. Não há suporte nativo para fornecer acesso a vários computadores através de uma rede, tornando-se uma má escolha como um sistema de banco de dados cliente/servidor.
- Replicação - Não tem suporte interno para replicação de banco de dados ou redundância. Replicação simples pode ser obtido copiando o arquivo de banco de dados, mas isso deve ser feito quando nada está a tentar modificar o banco de dados.
Sistemas de replicação pode ser construído na parte superior do API banco de dados de base, mas tais sistemas tendem a ser um tanto frágeis. Em geral, se você está procurando replicação em tempo real, especialmente em uma transação segura nível-você precisa olhar para uma plataforma de RDBMS mais complexa.
Então... Recomendo que use para substituir aquela sua porcaria de rotina que salva as informações em arquivos CSV e passe a usar algo realmente funciona e que é extremamente simples.
