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

Segunda Julho 6 14:46:56 UTC 2015

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