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

Segunda Julho 6 16:00:04 UTC 2015

A minha proposta é a mesma de antes (falta definirmos Wiki's links
perdidos), e me parece compatível com o seu levantamento:

* sem pensar: <ID, JSON> ou <ID, TEXT[]> ou seja, "FLEX";

* pensando (planejando o conjunto completo de dados, se surgirem demandas
joins e indexações):  <ID, chave1, chave2, restoFLEX>

O segundo parece mais chatinho, mas tem como automatizar no PostgreSQL.

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

>
> Dei um "apt-get -f install" que aparentemente arrumou as dependências do
> MariaDB.
>
> Consegui então instalar o Postgres 9.4 seguindo isso aqui:
> http://www.postgresql.org/download/linux/ubuntu/
> Vou ver agora se migro os dados do GA para ele e começo a colocar os novos
> dados de execução nele também.
>
> Sobre esses últimos conversei no canal do IRC do SQLAlchemy sobre a
> questão e
> me recomendaram ou usar uma coluna no BD para cada coluna da planilha
> (mesmo
> que várias delas vazias para alguns anos) ou usar o tipo JSON. Ainda não
> sei,
> mas acho que vou pelo JSON...
>
>
> Quoting Peter Krauss (2015-07-03 13:10:33)
> >
> >
> > Em 3 de julho de 2015 12:33, Andres MRM <andres em inventati.org> escreveu:
> >
> >
> >     Quoting Peter Krauss (2015-07-03 11:57:28)
> >     > 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.
> >     Basicamente são Integers e Strings. Mas tem datas também, menos
> relevantes.
> >
> >     > 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.
> >     As colunas basicamente são códigos (int) e a descrição de cada código
> >     (str).
> >     Aparentemente todos esses códigos são necessários para construir uma
> chave
> >     primária. Um jeito seria construir uma str que é a somatória de
> todos esses
> >     ints e colocar em uma nova coluna:
> >
> >             2015.23.49.8787.73898798
> >
> >     Mas, como disse antes, o número de códigos varia ao longo dos anos,
> então
> >     algumas chaves seriam compostas por mais ou menos ints.
> >
> >
> > Se tá difícil documentar na Wiki, pode ser um simples Excel (GoogleDocs)
> > mostrando exemplo dos cabeçalhos (não interessa tanto o tipo do valor
> mas ter
> > uma ideia da semântica para consolidar as chaves-candidatas ... Eu
> costumo
> > documentar com uma linha de cabeçalho e uma linha de exemplo, ou seja,
> duas
> > linhas a cada tipo de tabela).
> >
> >
> >
> >
> >     > PostgreSQL v9.3: por favor não perca tempo com versões anteriores,
> pois
> >     sei que
> >     > todos curtem JSON (!) na OKBr.
> >
> >     Esse é outro problema, a versão que há para instalar no servidor é o
> 9.1.
> >     Teria que puxar um mais recente dos outros repositórios e rezar para
> não
> >     quebrar outro pacote...
> >
> >     > 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,
> >
> >     Teria que ver qual o suporte do SQLAlchemy para JSON no Postgres.
> Porque se
> >     não for para usar SQLAlchemy teria que reescrever a API atual do GA
> também.
> >     E se fosse para ir por ai, me parece mais razoável migrar tudo para o
> >     MongoDB
> >     e pronto...
> >
> >
> > SQLAlchemy (ou o framework-SQL que for) não vai diferenciar tabela bruta
> de
> > VIEW-SQL,
> > a modelagem de dados inclui conceber as VIEWs.
> >
> >
> >
> >
> >     E outra coisa, deixando uma parte em JSON dá para cruzar os dados
> depois
> >     com
> >     as outras tabelas (ex: receita) "de boa"? Será que não vai dar tanto
> >     trabalho
> >     quanto interfacear com o Mongo via FDW?
> >
> >     >     - 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.
> >
> >     Em teoria o SQLAlchemy cuidaria disso sozinho. Seria só mudar o link
> para o
> >     BD
> >     nele e reimportar os dados. Mas nunca se sabe o que pode acontecer...
> >
> >
> > Mais uma vez, vamos documentar: outra coisa simples de colocar na Wiki é
> uma
> > descrição sucinta do atual modelo de dados, para conferir o grau de
> impacto (se
> > zero ou mais) das mudanças propostas.
> >
> >
> >
> >     > 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.
> >
> >     Bom, esse servidor É uma infra mínima unificada, e esse é o
> problema: puxa
> >     de
> >     um lado, quebra do outro... Isso quando não quebra sem nem ninguém
> entender
> >     o
> >     que foi.
> >
> >
> > Servidores com bom suporte a PostreSQL custam nos EUA o máximo US$10/mês
> (!!)
> > (para esse volume de dados e freq. de acesso que temos)
> > é um absurdo a OKBr não ser capaz de oferecer isso para os projetos..
> Mais
> > absurdo ainda um projeto de ~R$500k
> > não poder oferecer isso ao desenvolvedor.
> > ... Como eu coloquei antes, é uma questão de governança-OKBr (todos os
> > projetos)...
> > Eu sugiro uma reunião técnico-deliberativa (deliberativa!) sobre o
> assunto...
> > :-)
> >
> >
> >
> >
> >     _______________________________________________
> >     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
> >
> >
> _______________________________________________
> 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/20150706/9decd072/attachment-0005.html>