Stored Procedures no banco ou no aplicativo?
Olá,
Tenho lido o forum e ficou a dúvida (sou novato):
1 - Se colocar uma Stored Procedure no banco, e mais tarde tiver que alterar ou acrescentar alguma coisa, não é mais arriscado, já que para alterar você vai ter que mexer no banco, que muitas vezes poder ser muito grande, ou mesmo ter o risco de alterar algum dado?
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?
3 - Li que NUNCA deveria copiar um banco (Interbase) para outro sistema, e sim fazer um backup. Uso um sistema (de terceiros - ainda estou aprendendo) e algumas vezes o backup (que está junto no sistema) dá uma falhada. 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.
Agradeço qualquer ajuda
Tenho lido o forum e ficou a dúvida (sou novato):
1 - Se colocar uma Stored Procedure no banco, e mais tarde tiver que alterar ou acrescentar alguma coisa, não é mais arriscado, já que para alterar você vai ter que mexer no banco, que muitas vezes poder ser muito grande, ou mesmo ter o risco de alterar algum dado?
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?
3 - Li que NUNCA deveria copiar um banco (Interbase) para outro sistema, e sim fazer um backup. Uso um sistema (de terceiros - ainda estou aprendendo) e algumas vezes o backup (que está junto no sistema) dá uma falhada. 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.
Agradeço qualquer ajuda
Ratuna
Curtidas 0
Respostas
Aroldo Zanela
03/02/2004
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.
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.
GOSTEI 0
Afarias
03/02/2004
|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+
|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+
GOSTEI 0