MySql: LibMySql x ADO.

[Mario Mesquita]

Bom dia, amigos.

Pessoal, essa LibMySql serve para uso em produção, dá pra botar em cliente pra fazer a conexão com a BD?
Achei bem interessante para um iniciante como eu, apesar de estar vendo também como usar via ADO, com os excelentes posts do mestre Quintas e demais colegas.

Ou será melhor usar o ADO e não depender de ferramentas do Harbour? Mas se ela for usável, tem que ter aquela DLL ou seria o caso de incorporar a classe
dentro dos meus programas? Tem o fonte das classes que compõe a lib, é isso mesmo?

Desde já agradeço as opiniões dos colegas.

Saudações,
Mario.

[JoséQuintas]

Pessoal, essa LibMySql serve para uso em produção, dá pra botar em cliente pra fazer a conexão com a BD?
Achei bem interessante para um iniciante como eu, apesar de estar vendo também como usar via ADO, com os excelentes posts do mestre Quintas e demais colegas.
Ou será melhor usar o ADO e não depender de ferramentas do Harbour? Mas se ela for usável, tem que ter aquela DLL ou seria o caso de incorporar a classe
dentro dos meus programas? Tem o fonte das classes que compõe a lib, é isso mesmo?

ADO, hbMySQL ou SQLMIX, todas fazem uso da libmysql.dll que é fornecida pelo MySQL, ou pelo servidor ou pelo conector.
Qualquer que seja a opção vai instalar ou a DLL ou o ODBC ADO que contém a DLL.

No caso de hbMySQL e SQLMIX, a LIB do Harbour faz uso da DLL, então precisa gerar a LIB para a DLL específica, e distribuir essa DLL específica. A LIB do Harbour sozinha não vai funcionar, ela é apenas uma intermediária.
No caso do ADO, é parte do Windows, é como uma classe do Windows disponível para o aplicativo, mas depende de instalar o ODBC do MySQL, já que no Windows só vém ODBCs pra produtos Microsoft.

Usando SQLMIX, o retorno é tratado da mesma forma que DBFs.
Usando hbMySQL, o retorno é tratado como array.
Usando ADO, o retorno é tratado como recordset ADO.
Então, a primeira diferença é o tipo de retorno, pra cada um vai ter um fonte diferente, sendo que no SQLMIX é mais próximo de DBF, provavelmente aproveite melhor os fontes antigos.

SQLMIX é o que o nome diz: um MIX, de tudo que existe no Harbour.
Acaba podendo usar hbMySQL ou até ODBC através dele, o que expande pra bases não tratadas normalmente pelo Harbour.

Vantagens/Desvantagens de cada um?

- ADO é só Windows, faz parte do Windows, se tem ODBC/conector pra base de dados, é só usar.
Será mudança radical nos fontes.
As LIBs gráficas costumam fazer algo direcionado a ADO

- SQLMIX a vantagem é aproveitar fontes, o que pode ser muito bom na fase de migração.
A vantagem é tratar igual DBF, o que aproveita todos os controles voltados pra DBF
Talvez a desvantagem seja o programador esquecer que se trata de MySQL, e continuar pensando igual DBF.

- hbMySQL é totalmente por array, com certeza precisa mudança nos fontes

- Tem também a RDDADO, apesar de removida do Harbour 3.4, ainda está em extras do 3.2, e em algumas LIBs.
Seria usar ADO igual DBF, mas pra LEITURA, todo resto continua sendo comandos SQL.
Por ser ADO, só em Windows

Por causa das particularidades, tem dois pontos importantes a decidir:

- Se Windows ou Linux, isso já descarta opções
- Se aproveitar fontes é importante, isso também já descarta opções

De um modo geral, no MySQL é o servidor quem vai trabalhar, só haverá transferência de informação entre servidor e terminal.
Fica difícil falar em velocidade, se em todas dá pra enviar comandos para o servidor e trazer o resultado pronto.
Tirando as decisões acima, o resto é questão pessoal, como vai se sentir mais confortável, se com array ou dbf ou outro.
Em todas vai acabar enviando comandos pra inclusão, alteração e exclusão.

Desde o começo só usei ADO, não sei dizer em termos práticos se tem mais diferenças além dessas acima.

[Mario Mesquita]

Olá.

Quintas, entendi. Na verdade, estou inclinado a ir pelo ADO, reescrever os programas e realmente tentar "pensar" mais como SQL e menos como DBF.

Até porque só "pensar" como DBF vai me manter preso só no Harbour e pretendo conhecer algo novo, ando a fim de conhecer o Phyton e Javascript.

Vi suas postagens e não parece tão ruim de entender. Mas o recordset retorna o que, exatamente? Uma tabela filtrada?

Pretendo catar as postagens que abordam o MySql pra ter uma noção melhor.

Achei que a LibSql pode ser um facilitador por já tem algo pronto pra uso mas permite "pensar" como SQL. Ajuda na transição.

Sds,
Mario.

[JoséQuintas]

Mas o recordset retorna o que, exatamente? Uma tabela filtrada?

O SQL retorna uma espécie de "arquivo temporário", mas que não fica em disco.
No hbmysql é traduzido pra array, no SQLMIX é traduzido como se fosse DBF, e no ADO é o objeto ADO, sei lá se dá pra comparar com Access ou Lotus, ou SQL Server.
O ADO é uma classe que dá acesso a esse retorno, chamado de recordset.

Código: Selecionar todos

oTemporario := conexao:Execute( "SELECT * FROM CLIENTES" )
DO WHILE ! oTemporario:Eof()
   ? oTemporario:Fields( "CODIGO" ):Value
   ? oTemporario:Fields( "NOME" ):Value
   oTemporario:MoveNext()
ENDDO
oTemporario:Close()

Na verdade o ADO seria muito mais que isso, poderia até gravar e tudo mais, poderia até gravar 100 registros locais e só atualizar o servidor no final, acho que foi daí que veio aquele negócio do NET de trabalhar off-line.
Mas uso o recordset só pra leitura, pra não depender muito de recursos do ADO.
É o Execute() trazendo informação igual acima, ou só pra executar comandos sem retorno.

O Harbour praticamente só troca mensagens com o servidor, com ou sem resposta.

[Itamar M. Lins Jr.]

Olá!

Talvez a desvantagem seja o programador esquecer que se trata de MySQL, e continuar pensando igual DBF.

Talvez a desvantagem do ADO seja o programador esquecer que se trata de MySQL, e continuar pensando igual ADO.

SQLMIX
Será mudança radical nos fontes.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Talvez a desvantagem do ADO seja o programador esquecer que se trata de MySQL, e continuar pensando igual ADO.

Não, porque não uso NENHUM recurso do ADO, a não ser filtro em browse.

Ao contrário do SQLMIX, poderíamos trabalhar no ADO praticamente sem comandos SQL.
Eu NÃO faço isso.

[JoséQuintas]

Por exemplo:

Código: Selecionar todos

oTemporario:Fields( "NOME" ):Value := "JOSE"

NÃO uso isso.
Faço por SQL:

Código: Selecionar todos

UPDATE CLIENTES SET NOME='JOSE' WHERE CODIGO=10

Do outro modo sim, ficaria totalmente dependente do ADO.
Por comando SQL, tanto faz se é ADO, SQLMIX, hbMySQL, etc., é o mesmo comando em todos, e em qualquer linguagem de programação.

Por isso eu digo:
O mais importante é começar a migrar.
Se depois mudar de idéia, já não vai ser tão complexo trocar de um para o outro, nem mesmo se desistir do Harbour, o que seria algo extremo - só pra exemplo de como o SQL acaba sendo mais importante do que os "acessórios" pra uso dele.

[Itamar M. Lins Jr.]

Olá!
Pois é, com SQLMIX isso nem pode, só via SQL mesmo.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Pois é, com SQLMIX isso nem pode, só via SQL mesmo.

Mas isso acaba sendo vantagem, acaba sendo igual em qualquer coisa, não fica dependente, e nem limitado a recursos de SQLMIX.

Então.... incluir, alterar, excluir.... tanto faz se ADO ou SQLMIX, vai fazer do mesmo jeito.

Se for o caso, é criar uma rotina de executar(), e dentro dela colocar IF... SQLMIX... ELSE... ADO... E o aplicativo inteiro fica igual.
A diferença acaba sendo só o formato do retorno de informação.
Se com ADO usar a RDDADO fica parecido com SQLMIX, algumas LIBs fazem uso dele.

O importante é:
Se os dois usam igual, se alterar o fonte pra um ou pra outro praticamente dá no mesmo.
Qualquer dois dois que use, vai estar preparado caso mude de idéia.
É fazer os primeiros testes, comparar o que foi salvo quanto à codepage, etc., e fazer todos os testes que imaginar pra ver se tudo está ok.
Tudo ok, vai em frente.
Pode até testar todas as opções, sem problema, afinal, é até melhor decidir por conta própria.

Principal diferença entre Windows e Linux: NO SERVIDOR, o nome de bancos e tabelas no servidor Linux é case sensitive, mas no Windows tanto faz.
Se criar uma tabela CLIENTES no Linux, não pode usar como clientes.
No Windows, tanto faz.
Isso tem a ver com SERVIDOR.

Mostrei minhas duas bases no meu servidor Windows e na internet no Linux.
Uso Windows, mas pra usar MySQL do Linux da internet, tem que ser exatamente igual está lá "CLIENTES" e não "clientes"

[JoséQuintas]

Teste prático. No servidor Linux é obrigatório maiúscula/minúscula exatamente igual

No Windows tanto faz.

Estou usando Windows, mas isso depende do servidor e não do terminal.

[Mario Mesquita]

Olá.

Quintas, entendi. Bom, então pelo que vi, acho que fica entre o ADO e a LibMySql. O SqlMix pode até ser mais rápido de usar por aproveitar os comandos DBF,
mas tem o risco de se relaxar e não praticar o SQL. Se fosse algo na emergência até seria válido, mas ainda não é o caso. Mas é bom saber se algo acontecer e precisar de uma conversão rápida com pouco tempo de execução.

O ADO, seria bom ter alguma literatura ou site que se possa saber os seus métodos. A LibMySql, eu achei um tipo de manual básico que quebra o galho, tem o fonte da classe pra consultar e até já fiz algo nele, uma migração de uma base MySql para minhas tabelas DBF.

Adiante tento entender o que tenho que pôr no cliente além do MySql no servidor, ou seja como preparar as máquinas que vão acessar a DB, se tem que ter ODBC ou algo mais, confesso que sou muito cru. Como tenho umas máquinas meio antigas aqui comigo, devo montar uma pequena rede pra emular o básico dessas operações, fazer testes, etc. Por hora é criar a base, as tabelas e começar a "brincar" de usar o SQL.

Não esqueci sua dica de poder ter os dois, o SQL e o DBF operando, que permite uma transição suave e segura.

Sds,
Mario.

[Itamar M. Lins Jr.]

Olá!

O SqlMix pode até ser mais rápido de usar por aproveitar os comandos DBF,
mas tem o risco de se relaxar e não praticar o SQL.

Isso é lenda.
Tem que usar muito SQL, muito pelo contrário, tanto é assim que algumas pessoas optaram usar ADO, pois o ADO grava direto na tabela, e o SQLMIX só grava via sentença SQL.

Saudações,
Itamar M. Lins Jr.

[RamonXHB]

Boa tarde a todos.

Uso o ADO a bastante tempo, através de sentenças SQL, sómente.
A principal vantagem, no meu ponto de vista, é não ficar preso a nenhum banco, pois uso o mesmo programa com Mysql, Firebird, Sqlite, só trocando em um arquivo .INI qual o banco e a string de conexão.
Além de, numa hipotética troca de linguagem, poder aproveitar os comandos SQL.

No caso de uma mudança para linux, facilitaria a alteração para uso de ODBC puro, também suportado pelo Harbour.

[JoséQuintas]

Só um acréscimo:

Vamos supor que vai listar os clientes de SP.

Código: Selecionar todos

SELECT * FROM CLIENTES
DO WHILE ! Eof()
   IF cliente->UF != "SP"
      SKIP
      LOOP
   ENDIF
   SKIP
ENDDO

O fonte acima é simbólico.
Do jeito acima funcionaria, mas.... fica muito mais rápido pedindo só o que interessa.

Código: Selecionar todos

SELECT CODIGO, NOME, ENDERECO, UF FROM CLIENTES WHERE UF = 'S'
DO WHILE ...

Isso dá um grande aumento de velocidade, porque é menos informação pela rede.
Ao invés de trazer TODOS os dados, de TODOS os clientes, vai trazer só os clientes que interessam, e só a informação que interessa.

Num primeiro momento, não é ADO ou SQLMIX ou hbMySQL que vão deixar o uso mais rápido, e sim, fazer um bom aproveitamento dos recursos.

Isso é o tempo que vai ensinando, então quanto antes começar melhor, não importa se é com um conector ou outro.

Aliás..... nem sequer está preso a usar só um ou outro, pode até usar todos ao mesmo tempo, um módulo com cada um, ou até misturado no mesmo módulo, ou até tudo misturado também com DBF.
Não é obrigado a converter todo aplicativo pra uma coisa só, ou tudo de uma vez.

[Itamar M. Lins Jr.]

Olá!

Num primeiro momento, não é ADO ou SQLMIX ou hbMySQL que vão deixar o uso mais rápido, e sim, fazer um bom aproveitamento dos recursos.

É "puraí" o caminho !

Saudações,
Itamar M. Lins Jr.