Serializar para o DB

À pouco tempo, enquanto estudava Java IO descobri que é possivel serializar objetos. A minha pregunta é se é melhor guardar os objetos serializados no db ou guardar cada atributo individualmente?

Há: conjugação do verbo haver em sentido temporal.
à: junção de preposição + artigo e deve ser usado em referência a um elemento feminino.

Vamos lá.
Serializar é o ato de pegar um dado qualquer, em um determinado formato, e escrevê-lo em outro.
Alguns exemplos:

  • Transformar um objeto java em XML
  • Ler um XML e transformar em java (deserializar)
  • Transformar um objeto java em um JSON
  • Ler um JSON e transformar em java (deserializar)

O caso que você questiona é pegar o objeto, em memória, e gravar em um arquivo.
A melhor opção vai depender do que você quer fazer.
Se a ideia é manter estas informações para consultas futuras, independente de quando e tendo uma estrutura específica para armazenar e permitir consultas, banco de dados.
Se a ideia é só manter a informação temporariamente e não se preocupar com exclusão proposital ou eventual do arquivo, serialize em arquivo.

Vamos la

é totalmente possivel vc ter uma tabela com atributos ID e Objeto, sendo o objeto uma sequencia de bytes.

a forma de serialização é importante. se vc escolher um formato binario ( protocol buffers, etc ) ou texto ( json, yaml, xml, o seu formato customizado ) vc vai ter vantagens e desvantagens

formatos binarios:

pros:

  • vc pode ter alguma eficiencia em converter os bytes para o seu objeto
  • o formato pode suportar um tipo de atualização rapida ( adicionando bytes no final)
  • pode não ser facil de utilizar caso o banco de dados vaze para terceiros mal intencionados

contras:

  • vc só vai poder pesquisar por Id ou outros atributos que vc adicionar na tabela. se o seu objeto tem um campo Nome, vc não vai poder pesquisar no banco de dados pelo nome
  • atualizar o formato do seu objeto pode ser bem complicado. tenha um campo para versão em algum lugar ( seu objeto pode conter uma versão + objeto especifico )
  • bytes são faceis de corromper, considere armazenar um hash sha1/ms5 se for preciso
  • bytes são faceis de adulterar, considere assinar o hash se for preciso

formatos textuais:

pros:

  • facil de ler em uma consulta sql ( testes, debug, auditoria )
  • alguns bancos de dados podem entender o formato e oferecer coisas como busca dentro do objeto, retornar uma parte do objeto
  • vc tambem seria capaz de implementar uma forma de salvar “rapido” uma alteração adicionando algo no final cujo formato vc definiu ( pode ser um csv-like com timestamp + dados serializados em outro formato )

contras:

  • em geral é mais lento de processar
  • pode ser sensivel ao encoding da tabela/ database/ etc
  • mesmo q seu schema seja flexivel, vc pode ter problemas como: serializar um json de uma linguagem para outra pode trazer surpresas.

no geral

  • vc pode pegar um objeto com uma consulta a partir do ID (e é facil de fazer cache)
  • não utilizar todas as features de um banco sql, vc pode ocupar mais espaço pois os dados não serão normalizados ( as redundancias vão ficar em uma tabela, ao inves de ficar espalhadas por diversas tabelas, garantindo a integridade referencial, etc)

o que vc descreveu é a base de bancos NoSQL como Couchbase e Riak. Entretanto se vc precisa fazer pesquisas complexas, vc vai precisar OU usar features avançadas de pesquisa q nem sempre são boas (no Riak era pessimo nas versões 1.x ) Ou delegar para um mecanismo de busca como ElasticSearch (e descobrir os problemas do Refresh Rate)

em geral vc precisa estudar o problema que vc quer resolver. bancos sql sofrem de 2-phase commit e se vc insere muito ( mas muito mesmo ) vc pode sofrer de performance / disponibilidade / etc. aqui entra a discussão do BAC Theorem, ACID x BASE, etc.

eu sempre tento imaginar um sistema a partir de um banco sql (a menos q eu tenha serias restrições) e podemos analisar a aplicação afim de descobrir gargalos. depois de configurar bem, abusar de cache, second level cache, denormalizar dados, etc, ai da pra pensar em usar NoSQL pois a complexidade é outra.

por exemplo, se 2 pessoas alteram o mesmo objeto vc precisa detectar e tentar resolver o conflito de alguma forma. Quando vc decide adicionar um campo ou mudar o formato ai vc vai ver o PARTO que é alterar as coisas em pleno voo.

boa sorte