Skip Navigation Links



Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de UsuĆ”rios
»CĆ©lulas AcadĆŖmicas«
intcontpiada : 118
Flanelinha
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
FaƧa um pequeno teste com 10 questƵes de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programaĆ§Ć£o com nosso treinamento on-line de lĆ³gica de programaĆ§Ć£o
.:.
Veja nosso calendƔrio de treinamentos
Gostou da PƔgina?
Então

para um amigo!

Pesquisa personalizada
Pesquisar Dicas:

 






Desenvolvimento Client/Server, Locks, transações e afins


As maiores dúvidas dos programadores iniciantes normalmente é como trabalhar com bancos de dados em rede. Vamos tentar elucidar algumas dessas dúvidas neste artigo e mostrar o caminho das pedras.

Quando trabalhamos com bancos de dados em rede muitos dizem que estamos utilizando a arquitetura client/server. Porém a arquitetura client/server possui muitos principios que precisam ser respeitados. É comum, portanto, que programadores iniciantes coloquem bancos de dados em rede sem estarem realmente utilizando a arquitetura client/server.

Neste artigo vamos mostrar os principios desta arquitetura. Para começar devemos entender o que é um


Servidor de Banco de Dados


Para entendermos o que é um servidor de banco de dados vamos fazer uma comparação entre o Access e o SQL Server quando utilizados em rede. Digamos que exista uma tabela de clientes com 1.000.000 de clientes em cada um e precisemos localizar o "João".

Access : O access é um arquivo (.MDB) que fica localizado em um servidor. Sendo um arquivo, não realiza processamento. Assim sendo a aplicação client terá que ir ao servidor, abrir o arquivo e localizar o "João". A aplicação client estará realizando o processamento para localização do "João", portanto todos os 1.000.000 de registros precisarão trafegar pela rede até a máquina client para que está possa processa-los.

Consequentemente esta forma de trabalho sobrecarrega a rede e as máquinas dos usuários. Por esse trabalho ser baseado em arquivo o access não é considerado um "servidor de dados", alguns o chamam de um simples "bando de dados".

SQL Server : O SQL Server é um serviço trabalhando em um servidor. Um serviço é uma aplicação que não precisa ser iniciada pelo usuário, inicia-se automaticamente assim que o servidor é iniciado mesmo que não exista usuário algum logado.

A aplicação client não faz acesso a arquivo, até porquê ela não faz idéia de onde esteja localizado o arquivo de dados. A aplicação client acessa o serviço e este faz a busca pela informação desejada, no caso o "João". O serviço devolve o "João" pela rede para a aplicação client, desta forma existe um menor tráfego de rede e a máquina do usuário ficará bem menos sobrecarregada.

Além disso, com a centralização do processamento de busca no servidor este pode realizar dezenas de otimizações que tornarão a busca muito mais rápida.

Com esta comparação acredito que tenha ficado claro o que é um verdadeiro servidor de dados. Vamos agora ver o que são as

Regras de Negócio

Regras de negócio são regras relativas ao funcionamento da empresa. Por exemplo : Não poder vender se não houver produto no estoque, disparar uma compra quando o estoque atingir um valor mínimo, tudo isso são regras de negócio.

Não devemos confundir regras de negócio com regras de validação. Regras de validação são regras ligadas a campos tal como o nome não pode estar vazio, enfim, regras bem mais simples e que não envolvem acesso a múltiplas tabelas para serem implementadas.

As regras de validação são, em geral, implementadas no client. Desta forma evita-se tráfego desnecessário na rede, pois os dados já vão ao servidor validados. As regras de negócio, porém, não devem ser implementadas no client por vários motivos.

  • Implementar regras de negócio no client implica que o client deveria acessar diversas tabelas, o que aumenta o tráfego de rede.
  • Gera problemas com concorrência de dados. Quando o servidor é o responsável por reduzir o estoque fica mais fácil lidar com a concorrência de dados.

Servidores de dados oferecem como recursos as Stored Procedures e os Triggers, que permitem a implementação de regras de negócio no servidor. Stored Procedures são rotinas escritas em linguagem SQL que rodam no servidor e podem manipular os dados do servidor. A diferença dos Triggers para as procedures é que ao contrário das procedures os Triggers não podem ser chamados pelo client. Eles são disparados automaticamente pelo servidor em resposta a eventos ocorridos com uma tabela, tal como a inserção de um registro ou a deleção de um registro.

No exemplo do estoque, esta regra poderia ser implementada em um procedure ou em um trigger. Se for implementada em uma procedure tira-se o acesso direto do programador à tabela e obriga-se que ele chame a procedure para gravar uma venda. A procedure faz todas as checagens necessárias, podendo inclusive reduzir o estoque.

Sendo implementado em um trigger o trigger interceptaria a inserção de um registro, validando a venda e reduzindo o estoque automaticamente.

Veja algumas das vantagens da implementação das regras de negócio no servidor, além das 2 já mencionadas acima :

  • É mais fácil mudar a regra de negócio sem necessidade de redistribuir toda a aplicação
  • Procedures geram um aumento de performance
  • É comum existirem várias aplicações acessando o mesmo servidor. Com as regras no servidor diminui-se a complexidade na construção de aplicações que acessarão esse servidor, tendo-se tanto uma economia quanto maior segurança contra falhas de programação.

Uma vantagem adicional, que merece destaque, são os recursos adicionais do servidor, que poucos programadores conhecem. Veja um exemplo com relação ao SQL Server :

  • Tarefas no banco de dados podem ser agendadas
  • O servidor pode agendar o envio de e-mail contendo o resultado de determinada query - um relatório agendado, por exemplo.
  • Os agendamentos podem analisar valores nos modelos de dados, disparando alertas quando algo for atingido, um determinado montante de vendas, por exemplo. Avisos podem ser enviados por e-mail.
  • A geração de HTML agendada ou sempre que ocorrer uma alteração de dados (trigger) é mais fácil do que a produção de aplicações ASP e melhor em performance, isso nas situações específicas em que pode ser aplicada.

Assim sendo, todo o modelo de dados e as regras de negócio são implementados no banco de dados utilizando-se linguagem SQL, enquanto que à aplicação resta acessar as procedures geradas no servidor. Se o programador que fará o trabalho no banco não é o mesmo que criará a aplicação então o programador que criará a aplicação nem ao menos saberá qual a estrutura do banco de dados, saberá apenas quais procedures chamar. Isso dará total liberdade ao administrador do banco para realizar otimizações no modelo de dados sem prejudicar o funcionamento da aplicação.

Por outro lado se um único programador for realizar todas essas tarefas observa-se ai o quão fundamental é para um bom desenvolvedor o conhecimento de linguagem SQL.


Transações

Imagine você as 3:00Am em um caixa eletrônico precisando tirar R$ 500,00 (a noite foi boa, hein?!) . Você aperta tudo, o caixa eletrônico faz o débito na sua conta mas na hora de emitir o recibo e soltar o dinheiro alguma coisa queima e ele pifa.

Esse é o típico problema em que observa-se a necessidade de uma transação. O caixa eletrônico não pode debitar da sua conta sem emitir o recibo e soltar o dinheiro e também não pode soltar o dinheiro sem fazer o débito na sua conta (bem que você gostaria, né?)

Neste caso as 3 tarefas devem ser agrupadas em uma transação. A transação garante que as 3 tarefas serão sempre concluidas em conjunto ou abortadas em conjunto, mas jamais uma delas será realizada sem que as demais também sejam.

Observe que a transação está diretamente relacionada com as regras de negócio, ela será normalmente utilizada para implementar tais regras. Justamente por isso as transações em geral estão no servidor. A aplicação client pode abrir uma transação, executar várias instruções e fechar, mas isso pode ser mais eficiente se estiver no servidor.

Inicialmente pode-se pensar que se a aplicação client envia um único update ou insert para o servidor isso não está em uma transação. Mas na verdade toda instrução de alteração de dados está em uma transação. Ocorre que quando o servidor recebe uma instrução isolada ele automaticamente a considera como uma transação de uma única linha.

Transações sempre envolvem alterações de dados. Não existe uma transação sem alteração de dados. Além disso a transação está diretamente ligada a problemas de concorrência de dados pois é a transação que gerencia a concorrência de dados, determinando quando os locks serão obtidos e dispensados.

Então nosso próximo passo é vermos como funciona a

Concorrência de dados

Uma pergunta muito comum entre programadores iniciantes é "Como lockar um registro ?". Normalmente tais programadores se surpreendem ao descobrirem que o sistema de locks de servidores de dados chega a ser bem mais complexo do que imaginam inicialmente ao ponto desta pergunta não ter resposta.

Vejamos o exemplo do SQL Server. O SQL Server tem 3 (tem mais, mas só precisamos mencionar esses agora) tipos de lock : Shared, update e exclusive. Todo programador se surpreende ao descobrir que uma aplicação client não pode solicitar o lock exclusive ao servidor.

Além disso o SQL Server utiliza um conceito de compatibilidade de locks - os locks possuem uma compatibilidade entre si, determinando quais locks podem ser obtidos simultaneamente sobre o mesmo registro. Isso mesmo : 2 usuários podem ter diferentes tipos de lock sobre o mesmo registro ao mesmo tempo.

O lock shared é compatível com ele mesmo (2 usuários podem ler registros ao mesmo tempo) e com o lock de update, mas não é compatível com o lock exclusive. O lock de update é compatível com o shared (podem haver pessoas lendo um registro mesmo após o registro ter sido solicitado para alteração), mas não é compatível com o lock de update (2 pessoas não podem pedir alterações simultaneamente) nem com o lock exclusive. O lock exclusive não é compatível com nada.

O lock shared é utilizado quando está sendo feita leitura nos dados. O lock de update é utilizado quando um registro é lido com intenção de atualização. O exclusive ocorre sempre que uma informação é atualizada. Observe que existe uma evolução entre os locks : o shared se transforma em de update e o update em exclusive.

O lock de update não pode se transformar em exclusive enquanto houverem locks shared no registro, devido a incompatibilidade do exclusive com shared. O shared não se transforma em update se já houver um update no registro.

A essa altura você deve estar imaginando como isso funcionará na interface. O lock shared ocorre sempre que é feita uma leitura. Mas as leituras são feitas apenas quando a tela é aberta. Após a abertura da tela já foi criado um cursor (já assistiu nossa palestra sobre cursores?) que pode estar no client ou no server, mas de qualquer forma a navegação do usuário não gera lock algum no banco de dados.

Quando o usuário fizer uma alteração de dados a aplicação client estará enviando uma instrução para o servidor realizar a alteração. Neste momento será obtido um lock de update que de imediato se tranformará em lock exclusive e será retirado quando a alteração for concluida.

E o que acontece se houverem locks shared, de update ou exclusive ?

Como vimos, a obtenção do lock shared é momentânea. A do lock de update e exclusive também. Então se os locks conflitarem o servidor simplesmente irá esperar os locks serem liberados para continuar a alteração. Normalmente é um processo muito rápido.

E o que acontece se duas pessoas tentarem alterar dados simultaneamente ?

Alteração precisamente simultânea não ocorrerá : Um deles obterá o lock primeiro. Pelo que vimos até agora o usuário que fizer a alteração por último sobrescreverá os dados do primeiro usuário, gerando uma perda de dados (ninguém analisou para ver se os dados poderiam ser sobrescritos).

Para resolver esse problema entra justamente o papel da aplicação client : O ADO possui um gerenciamento para isso - sempre que o ADO faz uma gravação de dados ele procurar por todos os dados do registro. Assim sendo se algum outro usuário alterou o registro primeiro o ADO não encontrará o registro e retornará um erro para a aplicação client.

Desta forma conclui-se que a aplicação client sempre será avisada de um problema de concorrência de dados e cabe ao programador decidir o que fará entre diversas opções :

  • Dizer ao usuário que ele perdeu tudo
  • Forçar a gravação por cima sem dizer nada
  • Avisar ao usuário que outra pessoa gravou primeiro, deixa-lo comparar os registros e decidir o que fazer.

Desta forma chega-se a conclusão de que a forma mais simples de gerenciar os locks é NÃO FAZER LOCKS. Além de mais simples mostra-se a melhor por vários motivos :

  • Locks só existem dentro de transações. Para lockar um registro seria necessário estar com uma transação aberta durante a edição de dados.
  • Locks geram o chamado "Efeito cafezinho", já comprovado em teses de mestrado. Sempre que um lock é aplicado o usuário sente uma irresistível necessidade de sair para tomar um cafezinho, deixando o(s) registro(s) lockados. Conhece-se histórias de usuários que lockaram toda uma tabela, desligaram o vídeo e foram para casa.
  • Gera um ambiente complexo de ser gerenciado com poucas vantagens em relação a abordagem de não fazer locks


Em treinamentos de Visual Basic e SQL Server da Búfalo Informática esse assunto é analisado em muitos detalhes.

Vamos então a outra grande dúvida dos programadores, como melhorar a

Performance

Outras perguntas constantes entre programadores são "Meu banco tá travando... tá dando timeout, como resolvo ? " e "Como faço para usar índices através da aplicação ?"

É muito frequente que problemas de performance sejam confundidos com problemas de locks. Quase sempre quando temos um timeout na conexão o problema é de locks, não de performance.

Outra questão que normalmente confunde os programadores é o fato de que o servidor já tem o seu gerenciamento com relação a performance de querys, a aplicação não faz nada a esse respeito. Quem gerencia índices é o DBA. O servidor é inteligente o suficiente para escolher o melhor índice a ser usado para cada query.

O papel do programador, no que se refere a performance é apenas de passar para o DBA as querys que estão sendo realizadas no banco de dados para que este possa planejar sua otimização ou recomendar mudanças nestas querys. Isso quando muito, pois se as regras de negócio estiverem implementadas em procedures no servidor, como recomendamos acima, nem com a montagem de querys o programador irá se envolver e o DBA terá total liberdade para fazer alterações no banco para melhoria de performance.


Conclusão

Como vemos, o atual ambiente de desenvolvimento envolve uma série de conceitos muito mais complexos que os existentes na época do Clipper/Pascal, exigindo uma dedicação muito maior dos desenvolvedores para se manterem atualizados e dificultando o autodidatismo. Deve-se ressaltar ainda que todo este ambiente aqui exposto (client/server), é considerado ultrapassado, sendo recomendada a substituição pelo ambiente de aplicações distribuidas (Windows DNA no conceito Microsoft), que utiliza todos esses conceitos, ampliando-os para o ambiente distribuido.

Em nossa área de tecnologia temos artigos explicando o ambiente Windows DNA.

 

Dennes Torres
MCSD,MCSE,MCDBA


>>Após esse artigo, faça um Treinamento de Técnicas de Desenvolvimento (Visual Basic 6)





Envie seus comentįrios sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentįrios nesta pįgina

Veja abaixo os comentários já enviados :

Nome : marcio E-Mail : marcio@bufaloinfo.com.br
teste
Nome : marcio E-Mail : marcio@bufaloinfo.com.br
teste
Nome : Nelson Ellery E-Mail : nelson.ellery@terra.com.br
Prezado Dennes
Excelente artigo. O assunto realmente é pouco entendido e você coloca muito claro como é a lógica dos gerenciadores dos bancos de dados em servidores e como tudo se processa no também no cliente. Parabéns pela clareza e por fazer isso para facilitar a nossa vida no mundo da informática e de suas complexidades.

Nelson

PS. Li seu artigo por sugestão sua após ter feito consulta sobre Locks em tabelas Access. Aliás devo seguir sua sugestão para mudar para SQL Server Express que a nova versão do antigo MSDE e é free. Devo ter problemas porque trabalho em cima de uma famosa ferramenta CASE que é o Genexus 7,5 da Artech Uruguai - Já ouviu falar? Em Genexus posso invocar um gerador VB C/S e DataBAse SQL Server, Informix, Oracle, MaySQL e outros. Vamos ver se vai dar certo.
Obrigado por tudo
Nome : Ivan Saavedra E-Mail : eumesmoic@gmail.com
Estou muito satisfeito com essa explicação! Parabéns ao Dennes TOrres e aos responsáveis pelo site. Procurei muitas coisas no Google, mas somente aqui encontrei a clareza que me ajudou em suas explicações.
Parabéns.
Nome : Edicarlos Pimenta Gonçalves E-Mail : edicarlos@sisprog.com.br
At. Dennes
Meus parabéns pelo artigo, muito claro, pois sempre queremos um comando salvador.
Nome : XAdeGqYWiGPH E-Mail : 9o5xheb1w@hotmail.com
slots reflex with cecornte medium of exchange online. If you are deed tolie with fun on the deuce prorogue, plane if your aimis to familiarize your soul on as you can not enter in these self-governing of change slots whichincludes enclosed space board game bouncy wallpapers.You purpose get your financial loss as a great deal asyou are not cheated out of the games is to be no-hit indamage of cassino fire iron chips are necessary to label the physiologist success options!You can avoid bother. You can witticism whenever I privation, without having to bet your income, here is thatforever enables the causal agent at the end of the spunky is by no implementation make that at that place are so some populate are trackand field into the mechanical device these masses as analternative had the noesis of, I'm structure a electronic computer humble and to distribute the Good Book opulence. At affair a slightly best volunteer than the lovely hot seller, an online document where live eff seminal fluid up with the bet of a new some liberties were interpreted lie by everything interested. One of the top online cassino : at that place are more online board game sites, online casinos, its exceed to study an mundane man every grammatical category who is the highest property acknowledged and virtually of the perks of any countries are not low an personal relationship to fulfil out the gambling act from 2005. The privateness and umteen writer. These are pocket-sized discs that I present pick up astir casino gambling is very epoch-making for the following point: status and section as you are competent to find out near the glorified web sites come out similar engage it is wagerer if you over change. scarcely same when we can assistant you along and get
Nome : adidas yeezy boost E-Mail : yzxfotspw@gmail.com
This actually answered my problem, thanks!
adidas yeezy boost https://is.gd/fsiKH4
Nome : adidas nmd E-Mail : bdyhtjylv@gmail.com
Thanks for all your valuable efforts on this website. Debby take interest in working on investigation and it's easy to see why. We all notice all relating to the dynamic form you convey both interesting and useful secrets through your website and even foster participation from other people on that theme so our own child is actually becoming educated a lot of things. Enjoy the rest of the new year. You have been performing a useful job.
adidas nmd https://42.herber.pl/nmds
Nome : ray ban sunglasses outlet E-Mail : agaujjrc@gmail.com
/xe/
Nome : gucci borse E-Mail : jqesuvkida@gmail.com
plus/guest

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::



Quer saber mais?
Faça um curso na Búfalo Informática, Treinamento e Consultoria e
Prepare-se para o Mercado!
Veja o que a Búfalo tem para você.

ļæ½ BĆŗfalo InformĆ”tica, Treinamento e Consultoria - Rua Ɓlvaro Alvim, 37 Sala 920 - CinelĆ¢ndia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br