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

Sexta Julho 3 16:10:33 UTC 2015

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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150703/74ab6c44/attachment-0005.html>