SQL melhor forma de trabalhar.

[Itamar M. Lins Jr.]

Olá!
Estou aqui pensando como irei trabalhar.
Se ficarei checando lá no servidor via SQL ou puxando indexando quando os registros forem poucos.
Por exemplo, usuarios são no máximo 10 ou 15, no máximo 50 registros.
Um exemplo da IA.

Código: Selecionar todos

// Query segura que busca o usuário ativo e confere a senha
    cSql := "SELECT id, apelido, nome, nivel, liberapdv, senha " + ;
            "FROM usuarios " + ;
            "WHERE LOWER(apelido) = " + SqlVal( Lower(AllTrim(cApelidoInput)) ) + " " + ;
            "  AND ativo = TRUE " + ;
            "LIMIT 1"

    DbUseArea( .T., "SQLMIX", cSql, "Q_LOGIN" )

    IF Q_LOGIN->( Eof() )
        hwg_MsgInfo( "Usuário não encontrado ou inativo!" )
        Q_LOGIN->( DbCloseArea() )
        RETURN .F.
    ENDIF
 

Tem a opção de puxar, indexar e usar dbSeek() por exemplo, para não usar LOCATE, não uso LOCATE.
Pq em SQL tudo é no RETORNO da sentença.
Na WEB usando PHP/Python é assim(puxa o hash/json) e trabalha encima disso ou fica mandando via SQL o SELECT o tempo todo ?

[marcoprodata]

Não entendi direito a pergunta, mas em aplicativos web ou outros que se comuniquem com API, a gente manda o usuario e senha, e a API faz a validação do usuário e retorna um código HTTP padrão, exemplo 200 ok, ou 401 não autorizado.
Não precisa ficar retornando a tabela de usuários para o programa que requisitou para o mesmo processar localmente toda hora.
Outra questão, quando se trabalha com uma tabela tão pequena, se vai usar comandos SQL não precisa nem de indices, isso pra servidor SQL é milesimos de segundos pra processar e encontrar a informação.

[Itamar M. Lins Jr.]

Olá!
Olhei por aqui. Melhorou mais a visão da coisa toda.
Usando API, quando tem. E se não tem, é a mesma coisa com o Harbour(SQLMIX), usando PHP, Python tanto faz. Vem os registros para procurar e validar.
Pode ser Rest Full por exemplo. (API)
Pq quando tem API vc comunica usando protolo HTTP.
Precisa entender os protocolos.
Outra coisa que não precisa ficar puxando a tabela de usuários o tempo todo.
Puxa 1 vez só, valida e descarta, fica só com os dados necessários. Pode até se desejar criar uma tabela local (DBF/INI) etc...Depende da necessidade disso, as opções são variadíssimas.

Captura_de_tela_20260725_123446.png (102.28 KiB) Exibido 98 vezes

Agora é o refresh do browse, posicionamento do cursor no registro depois que mandar o UPDATE/INSERT em SQL, reler para ficar no padrão que eu gosto. Tá no Linux ai, o mesmo código do Windows, detalhe que a aparência vou cuidar disso depois, no Windows não fica com essa disparidade de cores nos icones.

[JoséQuintas]

Outra coisa que não precisa ficar puxando a tabela de usuários o tempo todo.
Puxa 1 vez só, valida e descarta, fica só com os dados necessários. Pode até se desejar criar uma tabela local (DBF/INI) etc...Depende da necessidade disso, as opções são variadíssimas.

Por isso eu recomendo o uso de ADO.
Ainda não entendeu nem que o SELECT geralmente trás um temporário.
Se é um temporário, nem precisa pensar em criar nada local, porque já veio na consulta.

[JoséQuintas]

Código: Selecionar todos

rs := cnSQL:Execute( " SELECT ..." )
DO WHILE ! rs:eof()
   rs:movenext()
ENDDO
rs:Close()

No caso do ADO, esse temporário é no formato ADO
No caso do SQLMIX, esse temporário é acessado como DBF
No caso do hbMySQL esse temporário é acessado como array
No caso de uma API poderia ser JSON, XML, ou outro
Mas o arquivo chamado local é justamente esse retorno.

Diferente de um aplicativo, a página web é algo que pode estar em outra máquina que não é o servidor, pode estar longe, em conexão discada, em computador, em celular, na TV com android, etc é isso que vai ser levado em conta na hora de decidir o que fazer.
As vezes pode ser interessante fazer mais uso do servidor, mas as vezes não.

[Itamar M. Lins Jr.]

Olá!
José Quintas ou qualquer um que queira participar.
Quando se inclui um registro, tanto faz em ADO, SQLMIX, RDDSQL, etc.
No caso de uso do browse, com 200, 300 registros, você(s) pegam inclui o registro por SQL e PUXA TUDO DE NOVO, ou INCLUI e ADD só apenas 1(novo) no temporário ? ADO, DBF, ETC ?
Pq na época que fiz isso com VB, era ADO, mas LIGADO no próprio SERVIDOR, tudo que fazia LOCAL já refletia no servidor.

[JoséQuintas]

Tudo vai de cada programador, não sei dizer o que é melhor ou pior.
Nos meus browses, uso recordset:Requery(), e isso é rápido.
Se é feita uma nova consulta do zero, ou se alguma coisa é aproveitada da pesquisa anterior não sei dizer.
Mas geralmente as pesquisas levam 1 segundo, não perco tempo medindo milésimos de segundo pra ver o que é mais rápido.

No ADO dá pra escolher o tipo de pesquisa, se vinculado ao servidor ou não.
Uso desvinculado sempre.
Uso assim desde o começo, não fiz testes pra ver se tem vantagem fazer diferente - adOpenStatic
É sempre consultar e jogar fora, se não for útil pra browse, ou pra do while em relatório ou processamento.

Acho que cada situação é um uso diferente, não dá pra definir um melhor pra tudo.
O que acontece com o passar do tempo, é que os bancos de dados e/ou acessos são ajustados pra tentar servir a toda necessidade de uma vez.

É isso que muitos ainda não entenderam.
Tudo caminha pra precisar de menos gente especializada.
A IA apenas deixou tudo mais claro sobre não precisar de ser humano.
No princípio da programação, usando assembler, o programador precisava se preocupar com cada bit disponível.
As linguagens evoluiram, pra facilitar pro programador (ou será que foi pra eliminar a necessidade de especialistas).
Isso também é uma evolução: empresas não precisarem de especialistas

Se preocupar com memória ?
1.000 produtos... ocupando 1.000 letras cada.... são 1MB, o cadastro inteiro é menor que uma simples imagem.
Para o navegador, isso é quase nada.
Mesmo em GUI, já enchemos controles de informação, fazer isso no navegador é mais do que normal.
Navegador é otimizado ao máximo pra aguentar coisa pesada, porque mexer com multimídia é pesado.
E essa capacidade é cada vez maior, se aguenta hoje, também aguenta no futuro.
Já deve estar sendo usada compactação, o que aumenta a capacidade de texto pra muito mais.
É o cadastro inteiro, ocupando menos que uma imagem.

Tudo bem, isso não significa desperdiçar, mas esse negócio de economizar memória já mudou muito desde a invenção do computador.
Lembrando: computadores do tempo do clipper tinham 640kb de memória.
O que hoje cabe uma imagem pequena, antigamente era o computador inteiro.
A informação em texto continua a mesma daquela época, o que mudou foi o uso de imagem.
Não é texto que vai consumir recurso do navegador.

Lógico.... quem já trabalha com isso pode dizer melhor, porque faz uso prático no dia a dia.

[JoséQuintas]

Pensando bem, acho que a gente já falou disso na época de usar GUI, e dialogs.
O fato de usar navegador não muda tanta coisa assim.
O framework passou a fazer parte do navegador.
A multithread passou a ser comum.
O que antes era uma tela, podem ser várias telas em abas diferentes.
Os recursos de memória/etc. controlados pelo navegador nunca foram tantos.
Ok, não são recursos infinitos, mas são gigantescos.
Mas é, realmente, tudo rodando no navegador, o navegador passou a ser o "sistema operacional" das coisas.
É o computador inteiro no navegador.
banco de dados.... vém o que precisar pra situação, suficiente até trocar de tela.

[Itamar M. Lins Jr.]

Olá!

Se preocupar com memória ?
1.000 produtos... ocupando 1.000 letras cada.... são 1MB, o cadastro inteiro é menor que uma simples imagem.
Para o navegador, isso é quase nada.

Sim, essa parte vou me preocupar depois, vou fazer os testes ainda, se chamo 100, 500, 1000 registros no BROWSE.
Essa parte de balanço, otimização é a melhor parte.
Por enquanto é o posicionamento do CURSOR do BROWSE da forma como era com DBF.
Quanto ao "problema" com ADO, não tenho problema nenhum, até usaria, mas não tem no Linux
Simples pq depois que muda para SQL, tanto faz ser ADO, SQMIX, etc.

[Itamar M. Lins Jr.]

Olá!

Mas é, realmente, tudo rodando no navegador, o navegador passou a ser o "sistema operacional" das coisas.
É o computador inteiro no navegador.
banco de dados.... vém o que precisar pra situação, suficiente até trocar de tela.

Por isso estou migrando para SQL/PostgreSQL/MariaDb/Etc. PQ é um padrão que irá durar por anos.
Mas como eu faço uso do LetoDbf, fiquei muito exigente com essas coisas, o LetoDBf é fantástico, naquilo que se propoe, mas tem mas coisas novas e o mundo avança.

[JoséQuintas]

Sai fazendo, depois vê o que dá
Se fizer webservice, tanto faz o que o webservice vai usar pro banco de dados, porque ele só vai dar o retorno.

[Itamar M. Lins Jr.]

Olá!

Sai fazendo, depois vê o que dá

Eu testo e retesto tudo antes. Nem tenho urgência disso, mas vou atualizar devagarinho, quando lembro de umas partes mais complicadas, chega a dar calafrios.
Só que não podemos abrir mão da IA, se isolar em uma linguagem ou banco de dados com as IAs ai dando sopa.
Uma das minhas metas é o -W3. Tenho muitas variáveis PRIVATE.