Fórum Stored Procedures no banco ou no aplicativo? #42051

Colega,

Stored Procedure como o próprio nome ja diz, refere-se a procedimento armazenado que é efetuado no banco de dados. Seu uso pode aumentar muito a performance num sistema quando bem utilizado, mas o particionamento da aplicação em n-camadas (ou três camadas) reduz o risco de interrupção de alguns serviços, bem como, facilita a construção da aplicação num projeto de médio a grande porte e as manutenções.

Sobre o terceiro item, não vejo problema se o banco estiver parado no momento que você faz a cópia, mas isso provoca interrupção do serviço.

|1 - Se colocar uma Stored Procedure no banco, e mais tarde tiver que
|alterar ou acrescentar alguma coisa, não é mais arriscado, já que {...}

Não há riscos desde q se saiba o q está fazendo. Stored Procedures são um recurso muito poderoso dos bancos relacionais e vale o ´investimento´ (mas cada caso é um caso)


|2 - Se a Stored Procedure está junto com o aplicativo, fazer uma
|alteração mexeria apenas no programa, que é bem menor em tamanho
|do que o banco de dados e os riscos não são menores?

Stored Procedures são algo exclusivo dos banco de dados -- o q vc pode fazer é mover regras de negócio para a aplicação cliente (ou mesmo para uma camada intermediária como bem citado por Zanela) -- quanto à alteração no código, os riscos são os mesmos.


|3 - Li que NUNCA deveria copiar um banco (Interbase) para outro
|sistema, e sim fazer um backup.

Exato! NUNCA! (A não ser q o serviço do IB esteja ´derrubado´)


|Uso um sistema (de terceiros - ainda estou aprendendo) e algumas
|vezes o backup (que está junto no sistema) dá uma falhada.

Como é isso??!!


|Então copio o GDB inteiro e colo num outro computador onde roda o
|mesmo sistema (utilizo o segundo computador como backup). Nunca
|percebi nenhum problema.

Mas um dia poderá! Vc está contando com a sorte. Se é um banco de desenvolvimento/testes não tem problema -- mas se é um banco de ´produção´ -- Be Ware!


T+