2016-06-07 15:30 GMT-03:00 Michel Luiz Milezzi <michelmile...@gmail.com>: >> 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 afirmou, pressupôs. Sua solução implica em que o problema é ser relacional, quando é justamente o contrário: não ser relacional é que complica o problema (que existe de qualquer maneira, mas não precisava ser tão grave). > Não entendi essa > sua colocação. Você distorceu o que eu disse. Não distorci, você que entrou em modo de defesa. Vamos com calma que chegamos lá. > Banco de dados 'semi-estruturado' não existe? Não, não existe. Por que estrutura ou há, ou não há; e se não há estrutura, há caos, não dados. Dados por definição são estruturados, o resto é márquetim. > Nem vou discutir muito com > você, basta uma olhada rápida na página do MongoDB para essa sua afirmação > cair por terra: O Mongo é contraexemplo de sanidade conceitual. Ele afirmar o contrário só ajuda a comprovar o que queremos explicar. > No mais, semi-estruturado não quer dizer que esteja mal definido. Não > generalize os seus casos, por favor. Generalizo, sim. Porque se não tem ao menos os conceitos relacionais, isso já é má definição. Nada ainda substitui o modelo relacional, mesmo que numa implementação ruim como é a do SQL — mesmo ruim é melhor que todas as outras que são ainda mais distantes do modelo. >> 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. Mas não são duas aplicações, até onde entendi, mas dois servidores de aplicação com duas versões diferentes dos mesmos aplicativos. Posso estar enganado, como sói acontecer. De qualquer maneira, permanece meu ponto: a questão aí não é usar ORM ou um gerador qualquer de código, é a disciplina de acrescentar ou aumentar, sem remover, alterar ou diminuir. >> > 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? Nenhuma. O exemplo é válido, só estou falando que não precisa ser Rest, basta separar a apresentação da lógica. > Vejo que você tem dificuldade > em aceitar a opinião alheia, então não vou me alongar muito na discussão Vou ignorar o ad hominem. > 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. CQD, o importante aí é o MVC, não o Rest. Vamos com calma que a gente aprende. Se defendendo não crescemos. -- 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
