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 <[email protected]> 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 <[email protected]> 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 > > [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 >
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
