[firebase-br] Stored Procedure

[paulosxs Yahoo!]

Prezado Sérgio, quanto à estratégia (usar SPs como camada) eu sou da 
mesma opinião, e, como já disse, é assim que procedo. Quanto à 
prioridade de alteração de registros pelos usuários, realmente há o 
risco de uma alteração de um usuário anular a alteração de outro 
ocorrida imediatamente antes. Mas, nesse caso, a questão é mais de 
arquitetura operacional do sistema. Isto é, se ambos os usuários 
possuírem permissão para a alteração de um mesmo registro, o sistema 
manterá o último a ter alterado. Três métodos que sugiro para amenizar 
este problema são:
1. Feedback: Após a alteração, o sistema exibe o que foi alterado. Nesse 
caso, a responsabilidade de checar a alteração é passada para o usuário.
2. Log: Antes de alterar, o sistema verifica se outro usuário alterou o 
registro há menos de X minutos (isso é feito a partir de um log de 
eventos). Nesse caso, o sistema retorna uma mensagem indicando que o 
registro foi recentemente alterado por outro usuário.
3. Status: Há atualizações que naturalmente protegem o registro na 
alteração da sua situação. Por exemplo, em uma agenda, dois usuários 
tentam agendar um mesmo horário. Quando o primeiro usuário reserva o 
horário, este fica automaticamente protegido para novos agendamento, 
originando um bloqueio para o segundo usuário.

> Date: Fri, 20 Jul 2007 20:09:26 -0300
> From: Sérgio Luiz Krüger <sergio.luiz.kruger em gmail.com>
> Subject: Re: [firebase-br] Stored Procedure
> To: "FireBase" <lista em firebase.com.br>
> Message-ID: <008e01c7cb23$0e791a60$3200a8c0 em SERGIO>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=original
>
>
>     Boa noite,
>
>     Obrigado pela ajuda, mas como voce controla na procedure update o caso 
> de duas estações estarem alterando o mesmo registro ? Se eu fizer uma 
> procedure update simples atualizando todos os campos que foram 
> acessados/alterados por uma estação, corro o risco de perder dados que foram 
> alterados em outra estação. É feito algum lock quando o usuário começa a 
> alterar o registro na tela ? Ou vc passa os valores antigos e novos para a 
> stored procedure gerar um comando update apenas do que foi alterado pelo 
> usuário ?
>
>     O que eu estou querendo fazer é criar uma "camada" de procedimentos no 
> banco de dados pra fazer manutenção em suas tabelas, tirando o máximo 
> possível a dependência de componentes e evitando assim de ter que ficar 
> escrevendo SQL dentro da aplicação. Fazendo dessa forma, acredito que a 
> aplicação poderia ser feita em Delphi, .Net, Java, etc, desde que a 
> linguagem suporte execução de stored procedures e ficando dessa forma, 
> padronizado o acesso aos dados. O problema é que eu não sei qual o padrão 
> que o pessoal utiliza, e tenho medo de começar a escrever código e no meio 
> do projeto, ter que alterar tudo.
>
>     Já pesquisei na net e existem casos onde os programadores efetuam um 
> select for update quando entram em modo de alteração do registro nas 
> estações, mantendo o registro "lockado" durante a fase de edição, evitando 
> assim o problema de duas pessoas alterando o mesmo registro, porém não sei 
> se essa é uma boa idéia.
>
>     Também encontrei casos onde é criada uma coluna timestamp na tabela que 
> é alimentada via trigger e na stored procedure update essa coluna é checada 
> na
> cláusula where a fim de saber se o registro foi editado por outra estação 
> enquanto voce estava alterando-o, fazendo com que o update falhe e o usuário 
> seja obrigado a reiniciar a transação.
>
>     Sei que devem existir outras formas de se fazer isso, mas eu gostaria de 
> saber quais são as melhores práticas, seus pontos a favor e contra pra poder 
> adotar uma delas e tocar o projeto.
>
>     Acredito que a maioria aqui usa Delphi pra acessar o Firebird. Será que 
> todo mundo usa escrever SQL dentro de componentes ? Essa é realmente a 
> melhor prática ? Se quiserem passar pra Java ou mesmo trocar de banco de 
> dados, reescrevem todo o SQL dentro de componentes de novo ?
>
>     Desculpe-me pelo longo e-mail, mas é que trabalho atualmente com Visual 
> Dataflex, e estou tentando converter minhas aplicações para banco de dados, 
> e já estou cançado de ficar dependente de uma linguagem ou banco, por isso, 
> procuro uma forma de fazer com que as coisas fiquem mais portáveis e 
> independentes uma da outra.
>
>     Abraços.
>
>     Sérgio Luiz Krüger
>
>
> ----- Original Message ----- 
> From: "paulosxs Yahoo!" <paulosxs em yahoo.com.br>
> To: <lista em firebase.com.br>
> Sent: Friday, July 20, 2007 7:05 PM
> Subject: Re: [firebase-br] Stored Procedure
>
>
> Em meus aplicativos adotei como padrão a interface com o BD sempre
> através de procedures. No caso dos componentes que utilizo, a transação
> é controlada automaticamente durante a execução da procedure. Quando se
> trata de uma procedure com um comando simples, os locks são gerenciados
> internamente pelo Fb. Pode ocorrer algum problema no caso de procedures
> complexas, que envolvam atualizações em várias tabelas, mas mesmo nesses
> casos nunca precisei me procupar com os locks.
>
>   
>> Date: Fri, 20 Jul 2007 09:54:17 -0300
>> From: Sérgio Luiz Krüger <sergio.luiz.kruger em gmail.com>
>> Subject: [firebase-br] Stored Procedure
>> To: "FireBase" <lista em firebase.com.br>
>> Message-ID: <004201c7cacd$1879cb50$3200a8c0 em SERGIO>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>     Bom dia,
>>
>>     Algúem da lista utiliza stored procedures para fazer 
>> insert/update/delete ?
>>
>>     Como funciona no caso do update ? É utilizada alguma forma de lock de 
>> registro antes de executar a stored procedure update ou a lógica de 
>> tratamento multi-usuários é tratada dentro da própria stored procedure ?
>>
>>     Alguém poderia comentar as suas experiências ou ajudar com algum 
>> exemplo ?
>>
>>     Obrigado.
>>
>>     Sérgio Luiz Kruger
>>