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

Sexta Julho 3 14:57:28 UTC 2015

Grande Andres, mão na massa!

Em 3 de julho de 2015 11:40, Andres MRM <andres em inventati.org> escreveu:

>
> 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:
>

Problemas são a nossa matéria prima, se registrar direitinho o mundo vai
perceber que trabalhamos ;-)

>
> - 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?
>

O primeiro para o coletivo aqui poder ajudar é  documentar: se precisar
ajudo, sugiro na
  https://github.com/okfn-brasil/cuidando2/wiki
é fundamental saber o perfil dessas tabelas (cabeçalho de colunas basta), e
ter uma legenda no que for relevante.
Em seguida entender o que seria "chave primária" (candidatos) de cada uma,
para avaliarmos se ao menos isso foi preservado ao longo dos anos.
PostgreSQL v9.3: por favor não perca tempo com versões anteriores, pois sei
que todos curtem JSON (!) na OKBr.
Se deixar as colunas "de chave" SQL-normais, e as demais colunas
codificadas num campo só com JSON, terá tudo de bom que já tinha no Mongo.
... e antes de bater o martelo num tabelão universal,
novamente discussão/documentação na Wiki: modelar dados é o paço seguinte
para decisões de projeto mais longevas e consensuais.

>   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.
>

Se formos bem-sucedido no passo anterior (pg v9.3) não será necessário.

>   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...
>

Esse HSTORE eu não recomendo, é legado histórico do PG, ficaria com JSON no
9.3+.

>
> - 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...
>
>
Essa parte é tranquila, posso ajudar.

> - 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...
>
>
>
*Infra da OKBr*: é um problema sério que nasce com os problemas de
governança.
Na minha opinião deveria haver uma infra mínima unificada, decente e para
todos os projetos.

> 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
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150703/223b1c57/attachment-0005.html>