E estava aqui penssando sobre as vantagens de escrever as funções sobre as tabelas de um banco de dados no próprio script do banco. Por exemplo, ao invés de escrever select * from tabela na minha aplicação java, não seria mais interessante fazer uma função para realizar essa operação no script do banco?
CREATE OR REPLACE FUNCTION inserir(/*parâmetro 1 */text, /*parâmetro 2 */integer) RETURNS BOOLEAN AS
$$
BEGIN
INSERT INTO tabela VALUES($1,$2);
IF FOUND THEN
RETURN TRUE;
ELSE
RETURN FALSE;
EXCEPTION WHEN OTHERS THEN
RETURN FALSE;
END;
$$LANGUAGE PLPGSQL;
e apenas chamá-la pela aplicação?
Assim, caso precise mudar de linguagem, não preciso mais me preocupar com o banco (select,update, join...) porque ele está independente da linguagem que pode ser java, c++, delphi...
Ou não faz diferença escrever no banco ou na aplicação?
Vale a pena criar funções no banco de dados e não na aplicação?[Resolvido]
4 Respostas
S
olha na minha opinião consoante o meu fraco conhecimento, eu axo que devemos deixar os select do lado do java, salvo que em alguns casos em que temos selects muito grandes eu axo que devem ser views porque depois fica um pouco confuso por no java, e alem disso eu axo que select onde tenham muitos calculos e subconsultas complexas se estiverem gravados na base de dados como views são mais rapidos a serem executados,
Agora chegando no teu exemplo cara eu axo que os insert ficarem na base de dados é um exagero porque a base de dados ficara um pouco confusa de se analisar os objectos (ou sei la eu reprovo completamente os insert, delete, update na base de dados),
O que eu acho que deve estar na base de dados alem das views, são algumas funções que executam calculos muito longos e demorados, porque ganha-se performance se for executado na base de dados
Mas isto depende muito da forma de como cada um gosta de organizar a sua aplicação
V
Ou não faz diferença escrever no banco ou na aplicação?
Com certeza faz diferença. Há vantagens e desvantagens.
Talvez a principal vantagem do script no banco é a performance.
O problema é que você perde portabilidade. O código está amarrado ao banco. Para cada banco você terá um código diferente para dar manutenção. Utilizando um framework como o hibernate você não terá esse problema.
S
tens toda a razão sem esquecer que tendo muita coisa no banco de dados ( pl/sql, funções) perdemos a portabilidade, mas as view podem ser inseridas normalmente quase todos os bancos de dados suportam
Certo, a primeira coisa a ser analisada é a portabilidade do seu sistema.
Principalmente se você estiver desenvolvendo um “produto de prateleira”, pode ser que você esbarre na migração para outro banco de dados.
Quando a desempenho, dependendo dos caso (hardware, distribuicao, versao etc), pode ser que seu banco de dados seja mais lento que a VM - vide numero excessivo de joins, selects etc.
A vantagem de manter “tudo” em banco de dados é que você diminui a complexidade de criação de telas na sua aplicação, deixando a cargo do DBA gerenciar tudo.
A desvantagem é o que foi dito anteriormente, você pede um pouco da portabilidade.
abraços!
Criado 24 de dezembro de 2009
Ultima resposta 24 de dez. de 2009
Respostas 4
Participantes 4