[Gastosabertos] Dúvidas com BD; Cuidando + Gastos Abertos; Servidor OK-Br

Sexta Julho 3 14:40:12 UTC 2015

Na última reunião de integração Cuidando 2.0 e Gastos Abertos (GA), tendo em
vista que o GA vai querer mais cedo ou mais tarde usar os dados de execução
orçamentária, fiquei de migrar os dados atuais do Cuidando (execução) do
MongoDB para o Postgres.

Comecei baixando todos os dados de execução do município de SP (até agora
estava usando só os de 2015) e "normalizando" essas planilhas:
https://github.com/okfn-brasil/gastos_abertos_dados/tree/master/Orcamento/execucao
(apenas os CSVs estão "normalizados")

Ia colocar então tudo isso no Postgres e começar a migrar a API que atualmente
usa o Mongo. Mas dai, é claro, sugiram alguns problemas:

- Os dados de execução ganham/perdem colunas ao longo dos anos, inclusive
  colunas de códigos que precisariam ser usadas para as chaves primárias.
  É claro que isso não impede o uso de um SQL, mas é um ponto favorável a um
  NoSQL, não? [1] Das alternativas que esse link cita, excluindo o Mongo, a
  mais razoável me parece ser usar o "EAV", que é praticamente usar construir
  um NoSQL dentro do SQL... Pesquisando mais sobre achei um documento que
  discute possibilidades de NoSQL dentro do Postgres [2]. O que ele parece
  recomendar é o HSTORE, que inclusive teria algum suporte via SQLAlchemy (que
  é a biblioteca que estamos usando em Python para acessar o BD). Alguém aí
  sabe se é uma boa escolha?
  Outra opção seria a que o Leonardo deu na outra conversa: manter os dados no
  Mongo e interfacear com Postgres usando FDW [3]. Mas essa última opção só
  parece fazer mais sentido se fossemos manter duas APIs distintas, o que não
  parece bom para o caso.
  Logo estou tendendo a experimentar esse HSTORE, mas não sei se ele vai gerar
  problemas para relacionar com os outros dados que já estão no BD, ou com os
  futuros dados geoespaciais...

- Além disso, pelo que consegui entender no servidor, os dados atuais de
  receita e contratos não estão em um Postgres, mas sim num MariaDB. Logo
  teríamos que migrá-los também para um Postgres... A não ser que alguém ai
  defenda deixar tudo no MariaDB. Não sei como é o NoSQL/GIS dele...

- Para deixar as coisas mais interessantes, não estou conseguindo instalar o
  Postgres no servidor. Por ironia do destino a instalação falha dizendo que o
  MariaDB precisa de uma versão mais recente (aparentemente isso está
  impedindo qualquer instalação na máquina). Ia tentar ver como atualizar o
  Maria, mas tive medo de perder os dados de alguém...

Abraços!

[1]: https://dba.stackexchange.com/questions/58036/how-to-handle-table-design-with-variable-columns
[2]: http://www.wmmi.net/documents/PGSQL-Schemaless.pdf
[3]: https://github.com/citusdata/mongo_fdw