2016-06-07 14:03 GMT-03:00 Michel Luiz Milezzi <michelmile...@gmail.com>: >> Não consigo imaginar uma maneira sistemática e (ou) automática. >> Dependendo das alterações, você pode criar visões que preservem o >> esquema lógico anterior, mas é trabalho braçal. > > Também não consigo ver uma forma de colocar isso na prática. Talvez seja o > caso de recorrer a um banco de dados semi-estruturado, não relacional.
Isso seria arrancar o nariz porque achou a cara feia. Para começo, o SQL também não é exatamente relacional, e isso (via dificuldades de atualização de visões e outros probleminhas decorrentes de violações do modelo relacional) é justamente uma das coisas que atrapalha esse tipo de trabalho. Depois, um ‘semi-estruturado’ não existe; o que existe é uma estrutura não tão bem definida quanto pode ser em SQL. E quanto mais mal definida, maior a dificuldade de lidar com versões e suas conseqüências. No caso, ‘semi-estruturar’ é varrer a sujeira para debaixo do tapete, e esperar que não tenha ninguém alérgico na sala… > Mas, se você utilizar um ORM para abstrair as consultas no banco de dados é > possível manter as entidades mapeadas de forma "diferente" em cada > aplicação. Neste cenário somente seria possível adicionar objetos novos no > banco de dados. Daria problema, por exemplo, se uma coluna fosse removida e > a mesma continuasse no mapeamento da entidade em questão em uma das versões > da sua aplicação. Isso nada tem a ver com ORM. ORM no caso vai é acrescentar complexidade numa abordagem muito simples, e geralmente insuficiente, que é de somente criar novos objetos. > De qualquer forma não recomendo estes cenários, o ideal é você tratar isto a > nível de aplicação. Por exemplo, é possível criar um ponto comum de acesso > ao banco para as duas aplicações através de um servidor REST. Este servidor > poderia tratar as diferenças entre as aplicações pela versão da sua api de > comunicação. Como mudam os nomes! Antes do Rest, chamávamos isso de três camadas. E implementávamos na própria base de dados, com as PLs. Não que isso anule o Rest; mas Rest é para outros casos, e incidentalmente pode ajudar nisso também. Em outras palavras, a questão aqui não é ser Rest, é isolar a apresentação (servidor de aplicações, no caso) da lógica (PLs, Rest, o que for). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
