Ah! Será que eu me enganei então? ehheh.. Minha intenção não era dizer que o Rails *substituia* as características supra-citadas de bancos de dados, mas sim que se você *quiser* pode fazer assim - o que poderia dar espaço para aplicações centralizadas no model da aplicação (o model do rails no caso).
Mas ainda acho que que o rails favorece isso - embora você tenha usado melhores práticas. Há uns meses atrás, no rails-br, algumas pessoas sugeriram que se o rails for o único a acessar o banco, o mesmo poderia ser feito sem chave estrangeira(já que daria pra usar o rails pra controlar isso). Pra felicidade de todos, a maioria achou isso um absurdo. Mas é o tipo de coisa que, embora não seja recomendável, é possível. (Será que agora fui mais claro?) []'s - Walter On 11/30/06, Rodrigo Hjort < [EMAIL PROTECTED]> wrote:
Walter, Na realidade no Ruby on Rails predomina justamente o contrário: você aproveita recursos do SGBD na tua aplicação. Por exemplo, se a coluna de uma tabela possui um valor default, o campo no aplicativo vem preenchido com esse valor. Algumas restrições também são validadas ainda na camada de visão, reduzindo a reescrita de código (no aplicativo e no banco). Outra coisa: já usei diversas vezes consultas em funções ou views e recebi como resultado objetos (instâncias de classes), e pude aproveitá-las sem maiores dificuldades na programação orientada a objetos. No Cedrus isso é usado bastante. Abraço, -- Rodrigo Hjort http://icewall.org/~hjort <http://icewall.org/%7Ehjort> 2006/11/30, Walter Cruz <[EMAIL PROTECTED]>: > Agora, voltando a vaca quente... > > No artigo, é citado o Ruby On Rails. > > "Em sistemas pequenos, a centralização da inteligência da aplicação dentro > de SGDBs é aceitável, porém com o aumento de aplicações Web e frameworks > como o Ruby On Rails, esta não parece ser uma tendência de longo prazo." > > Esse é um ponto interessante. O Rails permite que você faça algumas coisas > que não são possíveis em certos bancos de forma mais fácil. O seu banco > escolhido não tem integridade referencial (chave estrangeira), e não tem > como fazer um delete cascade (não é o caso do PostgreSQL)? O Rails faz pra > você. O seu banco é o Firebird, e você acha chato ter de criar uma trigger > para fazer o auto-incremento? Crie apenas o Generator, e o rails faz pra > você. O seu banco é o PostgreSQL e você gostaria de usar consultas > hierárquicas (ainda não disponíveis, previstas para o 8.3) ? Siga as > convenções, instale o plugin act_as_tree e seja feliz! > > Não estou exaltando o rails - mal uso ele. Mas ele propõe uma inversão de > valores - ao invés de ter as coisas centralizadas no banco, você tem as > coisas centralizadas no modelo da aplicação. Observem que o banco passa do > mínimo denominador comum, já que o esforço foi feito uma camada acima. > > Mas digamos que daqui a dois anos descubramos que o rails foi uma grande > ilusão, demos todos com os burros n'água. Precisamos migrar a aplicação para > outra linguagem. Acho que teremos uma grande dor de cabeça. > > O meu ponto é: o que é mais fácil de ser trocado? O banco ou a linguagem? Se > for o primeiro, concentremos nossos esforços na linguagem. Se for o segundo, > no banco. > > É só uma pequena opnião. Comentários e críticas são bem vindos. > > []'s > - Walter _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
_______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
