Se hoje se coloca a lógica em sistemas fora de SQL (dizer que são procedurais ou imperativos é besteira, existem sistemas com lóica em linguagens declarativas como XSTL) eu me pergunto quando isso não foi feito.

Ainda assim, não existe qualquerlimitação técnica para colocar regras de negócio na base de dados, seja em PL/SQL/ T/SQL ou mesmo Java -os sistemas de bancos de dados modernos suportam isso. Isso não acontece com fequência porque procuramos usar a ferramenta certa para o problema certo e banco de dados relacional certamente não é a ferramenta certa para qualquer coisa, mesmo que adicionemos esteróides como procedimentos em GPLs ao invés de apenas uma DSL como SQL.

Bancos são muito maiores que aplicações. Aplicações vão e vem, e as bases continuam.

De fato hoje tem-se de colocar lógica em programas procedurais (OO é procedural) fora da base, mas isso somente porque SGBDs SQL têm uma limitação arbitrária que impede que todas as regras organizacionais sejam declaradas como restrições de integridade.

Como subsistema, a View é algo como um skeleton RMI, umd etalhe de implementação.

Não importa se são usadas views ou não. O ideal é que não sejam mas se sua arquitetura corporativa usa bancos corporativos o ponto é que você deve tratar estes dados não como seu repositório mas sim como um subsistema integrado ao seu, com todos os cuidados normais a este tipo de integração.

Então, respondendo diretamente, desde que você isole o acesso aos dados e tenha em mente que o SGBD não é do seu sistema, é um subsistema, não há problemas em suar views ou acesso a tabelas, isso é indiferente neste aspecto.

Se você vai criar um componente que encapsule o cadastro ou não é algo que deve ser definido pelo arquiteto.

Por exemplo, um cadastro de funcionários de uma empresa. Quase todos, senão todos, os sistemas internos da empresa vão pelo menos ter que ter acesso de leitura aos dados dos funcionários. Uma abordagem muito comum é exatamente criar views, acessíveis a todos os sistemas.

Você sugeria que se crie um sistema de cadastro de funcionários, ao qual os outros sistemas pediriam dados, através de webservices ou algo do tipo? Isso não causaria um impacto na performance dos sistemas, além de aumentar muito a complexidade do todo?

Ou o que você sugere é apenas que encaremos o banco como um subsistema, e a view como uma ‘interface de integração’? Quero dizer, não importaria a tecnologia utilizada para esta integração, mas sim a separação das responsabilidades e a existência de interfaces bem definidas? E quando o acesso não fosse read-only, a integração seria feita via stored procedures? Ou aí sim algo webservice-like?