SQL é fácil

[JoséQuintas]

Muita gente acha o SQL complicado, porque a gente quer mostrar vantagens do SQL, e acaba mostrando sempre comandos mais complexos.
Mas é bem parecido com o DBASE, mas não tem comando USE pra abrir arquivos.

Código: Selecionar todos

USE CLIENTES
LIST
USE

Código: Selecionar todos

SELECT * from CLIENTES

com filtro e apenas 3 campos

Código: Selecionar todos

USE CLIENTES
LIST CODIGO, NOME, CREDITO FOR CREDITO > 5000

Código: Selecionar todos

SELECT CODIGO, NOME, CREDITO FROM CLIENTES WHERE CREDITO > 5000

Nesses dois exemplos acima, bem simples, no SQL já há um ganho extremo de velocidade, principalmente no segundo caso.
No primeiro caso, usando VARCHAR() no SQL, espaço em branco já não ocupa espaço/tempo de rede, além de vir compactado.
No segundo caso, apenas os campos solicitados vém pela rede, enquanto em DBF vém TUDO para o terminal escolher.
Isso é transparente para o usuário, é o servidor quem já faz isso.

De certa forma, DBASE e SQL são bem parecidos, há apenas uma mudança na forma de escrever, porque vai tudo numa única linha.
Se traduzir pra português então, tá fácil ver o comando.
SELECT = selecionar
FROM = de onde/origem
WHERE = aonde/filtro

selecione código, nome e crédito de clientes aonde crédito > 5000
SELECT codigo, nome, credito FROM clientes WHERE credito > 5000

É apenas questão de acostumar.

O que dá um "nó na cabeça", é sobre como uma simples troca de mensagens substitui todo aquele fonte que precisa pra DBF.

A demora em aprender a usar SQL.... não é por causa do SQL, é por causa do programador.
Quem nunca usou DBF até aprende mais fácil.
Já quem está acostumado com DBF, acha sempre complicado, porque sempre quer comparar com DBF.
Mas não tem comparação, é muito mais simples mesmo.

Acima trata-se de um único arquivo, quanto mais arquivos, maior a simplicidade em usar SQL.
Não vai mais precisar dos comandos USE, CLOSE DTABASES, SET INDEX, SET ORDER, SET RELATION, SEEK, LOCATE, GOTO, SET FILTER, SELECT, etc.
Se não precisa mais desses comandos.... como considerar que é mais complicado?
Concorda que o problema é o programador, e não o SQL? Que é porque está querendo comparar com DBF?
E quer comparar esquecendo de todos os comandos que o DBF precisa, tá comparando só o LIST, ao invés de toda parafernália de comandos USE, SET INDEX, SET ORDER, SET FILTER, etc. adicionais até chegar no LIST.

[JoséQuintas]

Vamos a um mais simples: quer o cliente de código 5.
Como costuma fazer no aplicativo???

Código: Selecionar todos

USE CLIENTES
INDEX ON CODIGO TO CLIENTES
SET INDEX TO CLIENTES
SET ORDER TO 1
SEEK 5

Em SQL

Código: Selecionar todos

SELECT * FROM CLIENTES WHERE CODIGO = 5

SQL é complicado?
Tente explicar pra alguém as duas formas acima.
Qual é a mais complicada?

Então.... o SQL é complicado pra quem usa DBF, porque ao invés de enxergar a facilidade, ele apenas vê que é diferente, e já considera complicado.

Na hora de aprender SQL, limpe a mente dos DBFs, apenas faça.
Depois faça igual em DBF, e se imagine explicando pra alguém como usar cada um.
Nessa hora você vai perceber como SQL é fácil, e DBF é complicado.

A gente nem costuma falar nisso, mas essa já é a grande vantagem do SQL: é fácil.

A gente até troca pensando na velocidade... mas ser fácil é a maior vantagem de todas.
Fácil de fazer, e fácil de dar manutenção.

[JoséQuintas]

A gente até troca pensando na velocidade... mas ser fácil é a maior vantagem de todas.
Fácil de fazer, e fácil de dar manutenção.

Voltando ao exemplo anterior.
No primeiro, se quiser mudar DBFNTX pra DBFCDX, mudar nome de índice, criar mais índices, etc. vai complicar.
Já no SQL.... NÃO MUDA NADA.

Se no SQL não precisa mudar nada..... como pode ser complicado?

Ficou muito tempo com DBF, e tá difícil SAIR DO DBF, não diga que o SQL é complicado, porque não é.
E quanto mais tempo pensar assim, mais vai demorar pra fazer programas mais fáceis, vai continuar usando USE, SET INDEX, SET ORDER, SET FILTER, SET RELATION, etc. coisas que NINGUÉM MAIS USA HÁ MUITO TEMPO, porque isso sim é complicado.

[asimoes]

Na tabela pode criar o indice para o campo que agiliza a pesquisa (SQL)

[JoséQuintas]

Sim, índices deixam o SQL mais rápido, mas basta criar os índices, não precisa mexer em fonte.

Se pedir coisa que não precisa, vai vir também, mas vai ser só perda de tempo/velocidade.

Se criar um índice por código, por exemplo, se o servidor achar que é vantagem, vai usar o índice.
NÃO é o programa que vai dizer pro SQL usar o índice, o servidor vai usar automaticamente da forma que decidir ser mais rápido.

O trabalho do programador vai ser USAR O SERVIDOR.
Como assim?
O servidor vai estar disponível pra fazer o trabalho do programa.
Quanto mais o servidor fizer, menos o programa precisa fazer.
É usar, e com o tempo vai descobrindo como tirar proveito, e colocar o servidor pra fazer mais do que apenas gravar informação.
NÃO é obrigado a fazer isso, mas.... porque não fazer? servidor trabalha local e muito rápido, quanto mais ele fizer, melhor.

Vai fazendo, vai acostumando, vai enxergando as possibilidades, e também pode pesquisar na internet, ou perguntar pra qualquer programador de qualquer linguagem de programação.
As possibilidades são infinitas, todo dia vai acabar pensando em alguma coisa que pode melhorar.
É só ver aqui no fórum: tem sempre alguém descobrindo alguma opção "nova".

[JoséQuintas]

Faltou dizer:

Com certeza tem muita coisa que não sei.
Vou usando conforme vou aprendendo.
Por enquanto meu conhecimento está atendendo as necessidades.

Posso adiantar que:
- foi vantagem usar nomes de campos padronizados pra cada tabela, por exemplo, IdCadastro no principal, e pdCadastro, fiCadastro, esCadastro em pedidos, financeiro, estoque, etc. facilita nos comandos por dispensar indicar de qual tabela eles são.
- foi vantagem mudar os campos chave pra numéricos
- foi vantagem deixar a numeração automática por conta do MySQL
- foi vantagem dividir as tabelas, ao invés de juntar várias numa só

Do jeito que fizer funciona, mas tem coisa que facilita.

Como descobrir o que facilita?
Vai usando, se mudar uma coisa e ficar mais fácil, é porque facilitou kkkk

[marco.prodata]

Uma outra grande vantagem em usar bancos SQL é a segurança, e diminuição drástica de possibilidade de corrupção de dados. No dbf o programa acessa diretamente os dados, no SQL não, você faz uma requisição ao gerenciador e ele te devolve o que pediu, ou implementa o que vc mandou, mas antes checa se está em conformidade.
O risco que se tem é se der defeito no disco do servidor e não tiver nenhum sistema de backup, mas gravação de dados corrompidos, chance praticamente zero.
Sobre índices, a minha forma de trabalhar é o seguinte, quando começo um sistema, geralmente não crio nenhum índice nas tabelas, mas sempre instalo nos servidores ferramentas de monitoração do servidor, que me dão as querys mais executadas e mais lentas, e faço um acompanhamento semanal, e medida q o banco vai crescendo ai, como trabalho com postgresql, utilizo explain nas querys lentas pra ver qual precisa de um índice pra otimizar, e qual o melhor índice, as vezes em uma query, apenas mudando a ordem dos wheres, faz com o interpretador do banco passe a considerar um índice já existente, lembrando q quanto mais índices, mais tempo demora a gravação do registro, logo, o ideal é ter só os índices realmente necessários.

[JoséQuintas]

Lembrando que índices são pra CONSULTAS.
Pra imprimir um relatório de clientes em ordem alfabética, não precisa existir índice por nome.
O índice por nome pode até existir, mas o SQL nem vai usá-lo pra nada, a não ser que faça uma consulta onde a chave seja o nome.

Aproveitando o que já foi comentado:
Se não existir índice nenhum.... mesmo assim tudo vai funcionar.
Pra o programa tanto faz, sempre trabalha do mesmo jeito.

Para o servidor, ele usa o que existir disponível, e que achar que vai ser mais rápido.
A única coisa que o servidor não faz é INVENTAR índices.
Talvez futuramente possam fazer isso, acho que nem falta muito pra isso existir, já que existem ferramentas onde eles mostram o que pode ser feito pra agilizar tudo.
É só pensar: se eles sabem dizer o que fazer pra melhorar.... só faltaria fazer.

[Fernando queiroz]

olha depois que mudei tudo para SQL a vida se tornou muito mais simples, acabou aquele monte de índices combinados pra fazer alguma coisa, hoje eu trago somente o que preciso e muito rápido, relatórios mais rápidos, fora algumas coisas que ficam muito simples tipo:

testar uma senha

SELECT password.ACESSO,IF(password.SENHA = SHA2('" + upper(RTRIM(::USUARIO) + RTRIM(::SENHA)) + "',0), 1, 0) AS SENHA, password.ATIVO FROM password WHERE password.USUARIO = '" + upper(RTRIM(::USUARIO)) + "'"

em resumo passei o teste da senha para o banco de dados, ele retorna um booleano com o teste da senha, uso o SHA2 para fazer a criptografia da senha em 64bits , e ta pronto, sem complicação

guardo somente a senha criptografada no DB usando o SHA2

[Itamar M. Lins Jr.]

Olá!

Tente explicar pra alguém as duas formas acima.
Qual é a mais complicada?

Aqui vc não está sendo IMPARCIAL.
Cortou comandos e mais comandos do ADO, etc que conecta e extrai os dados.
Aprender SQL não é apenas SELECT.

Por exemplo com "SET AUTOPEN ON" não precisa de abrir indices...
Cada um tem seus pontos fortes e fracos.
Tem empresa que vende CARO, MUITO CARO DATABASE DBF com "motor" cliente / servidor.
Tudo vai depender se o MOTOR do DBF aceita ou não SQL, ai já fica bem parecido.

Comparar linguagem SQL com DBF no meu ponto de vista não tem nada a ver.
SQL é apenas uma linguagem, e DBF não é uma linguagem.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
Nos seus exemplos comparando com o DBF, que é uma coisa que considero incorreto. Tem USE, etc... e usando SQL vc omitiu isso.
Seu próprio exemplo... Olhe ai DO WHILE..., SKIP, etc ?

Código: Selecionar todos

cnSQL := win_OleCreateObject( "ADODB.Connection" )
cnSQL:ConnectionString := "blablabla"
cnSQL:Open()
Temp := cnSQL:Execute( "SELECT ... FROM ..." )
DO WHILE ! Temp:Eof()
   Temp:MoveNext()
ENDDO
Temp:Close()
cnSQL:Close()

Então não é bom misturar SQL com DBF, para esconder comandos e desmerecer o DBF. Pois estão entrelaçados, uma coisa não funciona sem a outra.
Labutar com as respostas do SQL sem SKIP(MoveNext), ou seja lá o que for, vai existir sempre, com qualquer linguagem.
E isso não tem nada a ver com DBF.

Agora DBF é uma tecnologia que está sem continuidade e precisamos sair, abandonar por isso.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Nos seus exemplos comparando com o DBF, que é uma coisa que considero incorreto. Tem USE, etc... e usando SQL vc omitiu isso.

Sim e não, depende do ponto de vista.

No SQL você vai criar uma única conexão, e usar no aplicativo inteiro.
No DBF, isso ocorre centenas de vezes, mesmo que abra uma vez só no aplicativo, serão muitos USEs, porque a "conexão" é com CADA DBF.
Mesmo que existam exceçòes, o grande uso é direto com o DBF, sem cliente/servidor.

Se fosse colocar conexão do ADO/SQL, também teria que colocar mapeamento de rede pra DBF e outras coisas mais.
Também teríamos que falar sobre uso pela internet, etc.

Quanto ao DO WHILE/SKIP, não coloquei em nenhum exemplo, nem de DBF nem de SQL, porque são equivalentes (SKIP/Movenext), essa parte é igual nos dois, então não há o que mostrar.
Se acrescentei o SKIP na lista de "não precisar", foi por descuido.

Comparar linguagem SQL com DBF no meu ponto de vista não tem nada a ver.
SQL é apenas uma linguagem, e DBF não é uma linguagem.

Tudo bem, diga aí: vamos comparar o SQL com o que do mundo Harbour, pra explicar vantagens aos usuários?
DBF
RDD
hbMySQL
SQLMIX
Sintaxe dBASE
Sintaxe Harbour

À primeira vista, associar ao DBF, por causa do uso tradicional, parece a melhor opção, ou a "menos ruim".

[Itamar M. Lins Jr.]

Olá!

No DBF, isso ocorre centenas de vezes, mesmo que abra uma vez só no aplicativo, serão muitos USEs, porque a "conexão" é com CADA DBF.

Não é.
Usamos USE apenas uma vez para cada DBF. A mesma coisa com SELECT do SQL, para cada tabela usamos SELECT.
Depois de aberto o DBF(USE) usamos alias para ler, gravar etc pois ele já está aberto. O uso de select é opcional.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!

Mesmo que existam exceçòes, o grande uso é direto com o DBF, sem cliente/servidor.

Pois é.
Tem gente que fica usando o que funciona. Até começarem os problemas, depois procuram alternativas, temos LetoDb[f], ADS, 5 usuários com sintaxe SQL.
O problema como falei é uma tecnologia com poucos usando em 2021 e a maioria procura MySQL, Postgree,... os exemplos são para essas tecnologias, não adianta remar contra maré. DBF está em um nicho (arcaico), exótico, mesmo com toda essa revolução do Harbour, até os usuários xBase não sabem que o DBF do Harbour tem tanta coisa moderna, e fica sempre restrito esse conhecimento a poucos usuários as novas tecnologias DBF do Harbour é mistério para muitos.

Saudações,
Itamar M. Lins Jr.

[clauberromao]

o uso do sql se tornar necessario por conta o dbf esta tornando-se obsoleto, já estou utilizando sql ainda não repassado para cliente, apenas em testes internos
e agora queria iniciar teste de usar a conexão com coneção por ip, não mais por local host, o que tenho q fazer onde mudar?? quem poderia me ajudar passado o melhor caminho e para onde ir ?