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

[Andres MRM]

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.

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

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

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