Como arquivar seus documentos? FileSystem ou Database?

Essa dúvida ainda atormenta muitos decisores de TI quando buscam soluções de GED e ECM.  A questão é que algumas ferramentas usam o arquivamento em FileSystem e outras ferramentas usam o arquivamento em Banco de Dados.

Por que existe essa divisão?  Qual é a melhor opção?

Vamos a analisar algumas vantagens do uso do FileSystem:

1. Rapidez: O arquivamento em FileSystem é muito, mas muito mais rápido para gravar e para escrever.
2. Menor risco de perda: Os documentos em FileSystem são mais fácies de recuperar em caso de perdas do que um banco de dados corrompidos.
3. Menor custo de infraestrutura: O arquivamento em Banco de Dados torna a base muito lenta à medida que a base atinge um volume muito grande de documentos.  Como consequência, são necessários constantes investimentos em hardware, principalmente em memória para o consumo da base de dados.
4. Facilidade de migração: Extrair um documento não pode ser uma tarefa para gênios da programação, afinal, o documento pertence ao cliente e não ao fabricante de software. O problema é que não existe um padrão único para colocar os documentos em um campo blob do Banco de Dados.  Assim, é comum que algumas soluções encriptem o documento, ou coloquem vários documentos agrupados em um único campo, ou coloquem os metadados no mesmo campo de blob, ou ainda tudo isso junto, dificultando imensamente o trabalho de migração e, consequentemente, prendendo o cliente a uma solução obsoleta pela dificuldade em mudar ou mesmo resgatar um documento em caso de emergência.

 Então, se as vantagens são tantas, porque ainda existem soluções com armazenamento em Banco de Dados?

As razões estão relacionadas à segurança da solução de GED e ECM:

  • A primeira razão é porque, em algumas soluções antigas, o usuário tinha acesso direto ao FileSystem, tornando a aplicação insegura aberta demais.  Nas soluções mais modernas, o usuário nunca tem acesso direto ao FileSystem (ou storage do servidor), pois ele é um espaço de guarda e segurança onde somente o usuário do serviço pode ler e escrever através do servidor da aplicação, tornando a aplicação muito segura.
  • A segunda razão está relacionada à sincronização de dados. Se os metadados estão no Banco de Dados e os documentos estão no FileSystem, se perdemos ou banco ou storage, perdemos os dois.  A lógica é unir as duas informações em um mesmo local pois se for recuperar backup, recuperamos de um lugar só já sincronizado.  Este problema já foi resolvido há mais 20 anos pela solução de document imaging, Folder245, que encontrou uma forma simples, robusta e perfeitamente sincronizada:  unir metadados e documentos no storage, ou repositório, na forma de arquivos XML-like + documento.  Com essa configuração, o Folder245 recria o Banco de Dados íntegro, em alguns minutos em caso de perdas ou base corrompida. 



Conclusões: O que devemos adotar no arquivamento dos documentos, database em um campo blob ou filesystem em um storage?

Certamente, o arquivamento em filesystem é muito mais rápido, adequado a grandes volumes de documentos.  Ele também é mais fácil de recuperar em caso de emergência ou de migração e tem menor vulnerabilidade.  Para garantir a segurança de acesso e também a sincronização das informações de metadados e documentos, a melhor forma é usar ferramentas como Folder245ECM que restringe o acesso ao documento e arquiva uma estrutura XML-like que junto do documento tem todas as informações necessárias para recriar a base de dados.

Referências:

https://dzone.com/articles/which-is-better-saving-files-in-database-or-in-fil
http://lab245.com/GED/PRODUTOS.html#ECM

   

Comentários