>> - camada de apresentação separada da camada de aplicação.
>Como manda o mítico manual que está no céu, no divino Braço Direito do
>Criador? sem ironia.
Entrando no assunto ... o problema da área de informática é que vivem aparecendo novas soluções revolucionárias, novas ondas, novos modismos que são tratados como dogmas que se não forem seguindos ao pé da letra todos iremos para o infermo. ( sim com muita ironia, mas é verdade )
Um pouco de bom senso e flexibilidade nunca fizeram mal. Lógico que com arquitetura de 3 camandas dividir as camadas de apresentação, aplicação e dados é de maneira geral o melhor negócio. Porém isto não quer dizer que tudo precisa ir para a camada da aplicação, existem várias situações onde colocar parte da lógica de negócio no banco é simplemente a melhor solução em todos os aspectos.
O que vejo de novos sistemas feitos com a filosofia de tudo no servidor de aplicação onde grandes volumes de dados são transferidos do banco para o servidor de aplicação para serem tratados não é brincadeira e depois o pessoal de desenvolvimento ainda reclama que o sistema tá lento. Quando questionados se aquele volume de dados não poderia ser tratado no banco e somente o resultado final enviado para o servidor de aplicação a resposta é a filosofia de separação de camadas e de independência de banco recitadas como um dogma que nunca pode ser alterado, sem capacidade de fazer uma analise do que é melhor para cada situação.
>> Assim suprem-se as técnicas MVC modernas e ganha-se em portabilidade
>> (fica mais fácil migrar de SGBD ou misturar SGBDs)
>Na minha opinião ? e constato, aliviado, que na opinião de pelo menos dois ou
>três profiças muito mais inteligentes, experientes e bem informados que eu ?
>portabilidade total, dado que o SQL não é relacional e é muito mal
>implementado no mundo extraelefantíaco, é um mito, cuja busca tipicamente
>resulta em sistemas que nem são portáveis, nem corretos, nem manteníveis (eita
>palavriña orroroza, alguém tem alguma melhor?), nem escaláveis, nem sequer
>portáveis? eu ia dar o exemplo do Propvs liga, mas aí é chutar cão defunto.
Concordo esta onda de independencia de SGBD é o maior mito do mundo da informática, e que não passa de um ilusão da academia. Por até servir para sistemas e base de dados pequenos onde pode até ser que o cliente aceite ficar mudando de base, mas no mundo real dificilmente mudamos de base de dados porque dá um trabalho imerso e o ganho para o cliente na maioria das vezes não é significativo.
Um exemplo onde trabalho estamos um processo de downsizing de um grande, muito grande sistema do mainframe/ADABAS, que ficou uns 30 anos nesta plataforma, para banco relacional, arquitetura 3 camandas, etc. A previsão otimista é que vai levar 5 a 6 anos o projeto como um todo (lógico que ele vai ser implementado por partes), mas quem acredita que depois de todo este trabalho, com todos os impactos normais que isto vai causar para o cliente, você vai chegar para ele daqui a 8 anos e dizer ele que agora saiu o SGBD xyz e que vamos migrar o sistema de novo para este novo SGBD ?
Mesmo que a aplicação consiga ficar totalmente independente do SGBD, o que num sistema desde tamanho é quase impossível por questões de performance, só o trabalho de conversão dos dados de SGBD para o outro é uma grande trabalheira com riscos imersos. Na maioria das vezes grandes sistemas ficam décadas no mesmo SGBD, quando for necessário por algum motivo relevante a mudança da plataforma a tecnologia mudou tanto que aquele sistema que era teoricamente independente vai precisar ser todo codificado de novo de qualquer forma.
Abs,
Leandro Henrique Pereira Neto
Administração de bancos de dados - Serpro
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
