> > 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. >
Em qual momento afirmei que SQL É estritamente relacional? Não entendi essa sua colocação. Você distorceu o que eu disse. > 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… > Banco de dados 'semi-estruturado' não existe? Nem vou discutir muito com você, basta uma olhada rápida na página do MongoDB para essa sua afirmação cair por terra: "Developers are working with applications that create massive volumes of new, rapidly changing data types — structured, semi-structured, unstructured and polymorphic data." No mais, semi-estruturado não quer dizer que esteja mal definido. Não generalize os seus casos, por favor. > > > 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. > Veja, se as duas aplicações do amigo já estiverem usando um ORM para consumir o mesmo banco de dados, é possível utilizar mapeamento diferente nestas duas aplicações, desde que você não altere o tipo ou remova as colunas das tabelas que estão mapeadas. Você entendeu o que eu quis dizer? Não estou afirmando que é para adotar um ORM, estou dizendo que se o mesmo já for utilizado, é possível manter as duas entidades diferentes diante daquelas condições. > > 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). Qual parte do "por exemplo" você não entendeu? Vejo que você tem dificuldade em aceitar a opinião alheia, então não vou me alongar muito na discussão, mas Rest também é usado para estes casos, a nova stack da google, por exemplo, utiliza esta abordagem muito bem. Neste caso, o frontend (AngularJS) comunica com o backend (endpoints REST) em um modelo MVC. Uma abordagem de micro-serviços também utiliza comumente Rest. Você pode usar qualquer coisa como ponto comum de acesso ao banco, REST foi um exemplo, você pode usar SOAP ou o que quiser.
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
