Grande Andres, mão na massa! Em 3 de julho de 2015 11:40, Andres MRM <[email protected]> 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 > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br >
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
