USUÁRIO:      SENHA:        SALVAR LOGIN ?    Adicione o VBWEB na sua lista de favoritos   Fale conosco 

 

  Fórum

  Visual Basic
Voltar
Autor Assunto:  Teste prático: ADO X DAO (surpresa!!)
MARCONE
Pontos: 2843
BRASÍLIA
DF - BRASIL
Postada em 02/09/2005 15:11 hs            
Com a intenção de contribuir com os demais colegas, fiz alguns estudos e testes relacionados à
velocidade de processamento de grandes massas de dados. Nos testes utilizei apenas recordsets
por achar mais fácil a manipulação.
Tendo em vista o surgimento do ADO, faz mais de 4 anos que não trabalho mais com o DAO
que, inclusive, já fora descontinuado pela Microsoft. Achei bastante flexível o trabalho
com ADO na forma de rst. Apesar de processamento mais rápido, não gosto de trabalhar com
consultas SQL (insert into, update, etc...), pois entendo que são mais difíceis de se criar
instruções que detenham alguns parâmetros, como, por exemplo atualizações com critérios.
Como sempre manipulava pouca quantidade de dados de cada vez, não senti diferença
de performance entre DAO e ADO.
Há algumas semanas, surgiu-me a necessidade de fazer uma atualização de registros em uma base
de dados ACCESS 2000 com cerca de 110.000 registros. A tabela possui poucos campos e a base
fora compactada antes da operação. A atualização consiste, basicamente, em apropriar um valor
limite (sTeto) ao campo especificado. A forma de atualização está descrita no algorítimo abaixo:
'__________________________________________________________________________________________________
Private Sub AtualizaDados()
Screen.MousePointer = 11
Dim sTeto As Currency
Dim sCompAtual As String
Dim sCpfAtual As String
Dim sCompAntigo As String
Dim sCpfAntigo As String
Dim sVrAntigo As Currency
Dim iTotReg As Long
sTeto = 1869.34
sSql = "SELECT * FROM tblDuplicatas"
Rst.Open sSql, cnBd, adOpenKeyset, adLockOptimistic
Rst.MoveMin
sCpfAntigo = Rst!Cpf
sVrAntigo = Rst!Total
Do While Not Rst.EOF
Rst!Processado = "S"
    If sVrAntigo < sTeto Then
        Rst!VrBase = sVrAntigo
        sTeto = sTeto - sVrAntigo
        ElseIf (sVrAntigo + 0.01) > sTeto Then
            Rst!VrBase = sTeto
            sTeto = 0
    End If
Rst.Update
Rst.MoveNext
If Not Rst.EOF And Not Rst.BOF Then
    If sCpfAntigo <> Rst!Cpf Then
        sCpfAntigo = Rst!Cpf
        sVrAntigo = Rst!Total
        sTeto = 1869.34
        Else
        sVrAntigo = Rst!Total
    End If
End If
Loop
FecharRst
Screen.MousePointer = 0
MsgBox "Atualização efetuada com sucesso ", vbExclamation, "Apuração da Base de Cálculo!!"
Exit Sub
End Sub
'__________________________________________________________________________________________________
Quando processada uma quantidade inferior a 6.000 registros, não houve grande demanda de tempo;
mas para minha surpresa, quando mandei processar a tabela com mais de 104.000 registros, o processamento
demorou mais de 4 horas para ser concluído.
Não conformado com tanta demora, resolvi migrar o banco para MySql e para Firebird e a demora foi ainda
superior às 4 horas obtidas no Access.
Por acaso, resolvi processar o código acima usando o DAO com ACCESS 2000 e tive uma SUPRESA!!!!
O processamento de atualização feito com DAO foi muito mais rápido (em segundos), se comparado com ADO.
Abaixo, segue a tabela com as conclusões:
BdDadosM (12.229 registros)
Ado: 00:00:32
Dao: 00:00:07
BdDadosG (82.062 registros)
Ado: 00:02:54
Dao: 00:00:32
BdDadosGG (104.623 registros)
Ado: 04:19:05
Dao: 00:00:40

Depois do resultado, acabei concluindo que ainda não aprendi a trabalhar com ADO, vez que a diferença
no processamento das informações, em relação ao DAO, é de grande relevância num programa. Assim sendo,
gostaria de saber se a forma acima é a melhor de se trabalhar com o ADO, ou se sua performance só
melhora utilizando-se de consultas ação (INSERT INTO, UPDATE..).
Se alguém tiver alguma crítica ou sugestão, gostaria que colocasse para discussão, principalmente, se
o código de atualização postado acima estiver com alguma inconsistência (na prática, ele funciona)..
É isso aí..

MarconeEmoções

 

     
Roßerto
Pontos: 2843 Pontos: 2843 Pontos: 2843 Pontos: 2843 Pontos: 2843
SAO PAULO
SP - BRASIL
ENUNCIADA !
Postada em 02/09/2005 20:31 hs            
Marcone eu já esse teste uma vez e obtive os mesmo resultados que o seu.
eu tenho projetos que ainda usam o DAO, mas eu só uso DAO em determinadas situaçoes
por exemplo, em projetos que tenham no maximo 5 maquinas conectadas, usando access
97/2000 e nao tenham um volume de dados muito grande.
mas esses testes só valem para o Access, para outros tipos de BD, o ADO é bem melhor.
 
 

Roberto
roberto@vbweb.com.br
   
kerplunk
Pontos: 2843 Pontos: 2843 Pontos: 2843
SÃO PAULO
SP - BRASIL
ENUNCIADA !
Postada em 02/09/2005 23:01 hs         
Bom, todo esse procedimento acima pode ser executado com uma única query update, se puder me mandar um mdb contendo essa tabela, eu faço a query pra vc.
   
ghost_jlp
Pontos: 2843 Pontos: 2843 Pontos: 2843 Pontos: 2843
SÃO PAULO
SP - BRASIL
ENUNCIADA !
Postada em 03/09/2005 18:27 hs            
Fique preocupado agora... vc utilizou o mysql e o firebird e o resultado foi q demorou ainda mais q o access?? Alguém poderia me esclarecer isso?!?! Emoções
Entendi errado?
   
Sandro
não registrado
ENUNCIADA !
Postada em 04/09/2005 00:20 hs   
Olá,
 
Marcone, o seu teste foi interessante, mas eu gostaria apenas de comentar dois pontos que acho importante serem observados:
 
1. A Microsoft não descontinuou a DAO, como você disse. Ela continua existindo em todas as versões do Access. A Microsoft tem preferência pela ADO, devido ao fato dela ser mais flexível que a DAO, mas o Access continua dependendo da DAO para executar código VBA e acessar muitos dos seus recursos internos;
 
2. O teste que você realizou foi feito com um banco de dados MDB do Access usando a ADO e DAO. Até aí tudo bem, mas você não deve se esquecer que a DAO foi desenvolvida especificamente para usar bancos de dados Access, enquanto que ADO não. Ela foi desenvolvida visando o acesso à várias bases de dados diferentes, portanto ela não é uma interface "dedicada", ou "especializada", mas sim uma interface genérica, como o ODBC, só que mais nova e com mais recursos. A DAO foi desenvolvida para bancos de dados Desktop, e eventualmente pode trabalhar em rede com múltiplos acessos simultâneos e com bases de dados diversas usando ODBC ou ISAM (acesso indireto). A ADO foi desenvolvida para acessos a bancos de dados Cliente/Servidor em redes grandes, principalmente a Internet e "também" pode acessar bases desktop com acesso direto pelo OLEDB. Percebeu a diferença? Pelo fato de não ser voltada especificamente para um tipo de banco de dados, ela sempre terá um desempenho inferior ao gerenciador padrão daquele formato de banco.
Mas veja, que quando falamos de acessar SQL Server ou Oracle, a DAO é mais lenta que a ADO, além de não suportar todos os tipos de dados desses gerenciadores. Em rede, a ADO se mostra mais eficiente e estável. Na internet então, a ADO pode ser usada diretamente em páginas ASP, já a DAO não, porque ela não é Cliente/Servidor.
Você testou o banco de dados em MySQL e FireBird, mas usou o quê para acessar esses bancos? Provavelmente usou a ADO, mas como você não disse nada a esse respeito, eu pergunto, tentou acessar esses bancos usando a DAO? Imagino que não. Se testou, por favor, coloque também o resultado que obteve, mas se não testou, faça o teste e veja o que acontece. Provavelmente o resultado será mais quatro horas de processamento.
 
um abraço,
Sandro.
   
MARCONE
Pontos: 2843
BRASÍLIA
DF - BRASIL
ENUNCIADA !
Postada em 04/09/2005 11:15 hs            
Usei a mesma forma em Access para acessar o MySql e Firebird (ADO), mudando apenas a forma de conexão:

'CONEXÃO COM O FIREBIRD:
Private Sub cmdConectar_Click()
Dim cnBdFirebird As New ADODB.Connection
Dim rstBdFirebird As New ADODB.Recordset
Dim sSqlBdFirebird As String
Dim sBANCO As String
sBANCO = "BdDados.FDB"
cnBdFirebird.ConnectionString = "DRIVER=Firebird/InterBase(r) driver;UID=SYSDBA;PWD=masterkey;DBNAME=" & App.Path & "" & sBANCO
cnBdFirebird.Open
sSqlBdFirebird = "Select * From TBLDUPLICATAS"
rstBdFirebird.Open sSqlBdFirebird, cnBdFirebird, adOpenStatic, adLockOptimistic, adCmdText
'MsgBox "conectei"
Me.lblTotalRegistros.Caption = "Total: " & rstBdFirebird.RecordCount & " registros"
'MsgBox "Nome: " & rstBdFirebird!NM_NM_EMPR
Set Me.DataGrid1.DataSource = rstBdFirebird
Me.DataGrid1.Refresh
Screen.MousePointer = 0
End Sub
'CONEXÃO COM MY SQL:
Set gConexao = New ADODB.Connection
gConexao.ConnectionTimeout = 60
gConexao.CommandTimeout = 400
gConexao.CursorLocation = adUseClient
gConexao.Open "DRIVER={MySQL ODBC 3.51 Driver};" _
                      & "user=" & sNomeUsuario _
                      & ";password=" & sPassword _
                      & ";database=" & sBancoDados _
                      & ";server=" & sHost _
                      & ";option=" & (1 + 2 + 8 + 32 + 2048 + 16384)
Me.MousePointer = vbNormal
If gConexao.State = 1 Then
     SaveSetting App.Title, "Settings", "sHost", sHost
     SaveSetting App.Title, "Settings", "sNomeUsuario", sNomeUsuario
     SaveSetting App.Title, "Settings", "sBancoDados", sBancoDados
     'MsgBox "Conecção efetuada com sucesso!!"
Else
   MsgBox "Não foi possível estabelecer a conexão. Verifique as configurações e tente novamente.", vbCritical, "Erro durante a conexão..."
End If
 
 
kerplunk, mandei o projeto com os testes para você tentar converter o código para SQL Update..
 
Creio que a lentidão esteja na forma de manipulação dos dados. Continuo achando que as consultas SQL são mais rápidas que os recordsets colocados acima; de qualquer forma, farei outros testes para ter certeza disso.
 
Ainda não fiz os testes com SQL SERVER, creio que essa semana terei tempo para isso..

MarconeEmoções

 

   
Página(s): 1/2      PRÓXIMA »


Seu Nome:

Seu eMail:

ALTERAR PARA MODO HTML
Mensagem:

[:)] = 
[:P] = 
[:(] = 
[;)] = 

HTML DESLIGADO

     
 VOLTAR

  



CyberWEB Network Ltda.    © Copyright 2000-2024   -   Todos os direitos reservados.
Powered by HostingZone - A melhor hospedagem para seu site
Topo da página