PC Toledo

Tô pensando nesse troço aí....
E até pra muitos entenderem o porquê de às vezes complicar pra facilitar.

SELECT 1 AS A, 2 AS B, 3 AS C

Dá pra interpretar isso de duas formas:

Está criando as variáveis A, B e C
Está criando um equivalente a DBF, contendo os campos A, B e C

Fica chato criar com vários registros, mas é a opção disponível:

SELECT 1 AS A UNION SELECT 2 UNION SELECT 3

Primeiro cria o "temporário" com o campo A e conteúdo 1, e vai unindo com outros temporários com 2, 3, etc.
O resultado é equivalente a um DBF, contendo o campo A, e 3 registros onde cada registro contém o campo A, mas cada um tem seus próprios valores 1, 2, 3
É como se estivesse somando arquivos: arquivo1.dbf + arquivo2.dbf + arquivo3.dbf

E aqui chegamos a um ponto interessante:
É como se o SQL fosse feito pra fazer operações com arquivos (ou serão arrays?)
Ou, como acostumamos a chamar no SQL: TABELAS.
Pois é... TABELAS.

Acho que não pensamos nisso antes, o que são.... TABELAS ?
Um DBF é uma tabela, um array é uma tabela, uma lista de variáveis pode ser uma tabela.
Pois é....
é operação com tabelas.

SELECT 4 AS A
Isso criou uma tabela com o campo A e conteúdo 4

SELECT 5
Isso criou uma tabela com um campo de conteúdo 5

SELECT 6
Isso criou uma tabela com um campo de conteúdo 6

( SELECT 4 AS A UNION SELECT 5 UNION SELECT 6 ) AS TABA
Isso somou as tabelas, e como resultado, vai ser uma tabela de nome TABA com 3 registros, contendo o campo A, e conteúdos 4, 5, 6

SELECT A * 3 FROM ...
Isso vai usar a tabela indicada no from, e retornar o campo A vezes 3
4, 5, 6 vezes 3 resulta em 12, 15, 18

Pois é...
Apesar de no princípio dar um nó na cabeça, basicamente é operação com tabelas, coisa que não estávamos acostumados.
Ou será que só não estávamos enxergando?
O que dizer disto?

? dbEval( { || a * 3 } )
? AEval( || a | a * 3 } )

Usando isso acima, fazemos cálculos com tabelas, que pode ser DBF ou Array.
No SQL, tudo é considerado tabela, o próprio SQL acaba fazendo esse papel de codeblock.

Interessante isso: de repente o SQL parece juntar DBF, Array, codeblock, tudo junto, tudo diferente, mas tudo igual... igual, mas diferente.

Então... a vantagem do SQL é deixar mais fácil trabalhar com informações como se tudo fosse tabela.
Até um simples SELECT, trata-se de extrair parte ou toda a tabela, seja tabela que existe na base de dados, seja tabela criada no comando.

Esse conceito pode facilitar entender porque às vezes a gente usa um comando "monstruoso".

( SELECT 4 AS A UNION SELECT 5 UNION SELECT 6 ) AS TABA

Esse "monstrinho" acima, é só uma forma de transformar 4,5,6 no formato de uma tabela.
Mesmo sendo um comando grandinho (para o que ele gera), é uma tabela, coisa que para o SQL trabalhar é rápido.

Cheguei nessa conclusão agora, que estou dando uma olhada em cálculo nos produtos do pedido.
Dá pra fazer UPDATE de SELECT de SELECT, o que na prática é transformar essas informações em tabelas, e fazer os cálculos nessas tabelas, e gravar os resultados dessas tabelas, tabelas que podem ser reais ou criadas no comando.

É interessante ver por esse ponto de vista.
Até mesmo pra criar o comando SQL, podemos criar várias "tabelas temporárias" no mesmo comando, pra organizar "as coisas".

Aí tem a questão de deixar rápido.
Como deixar rápido?
Criando tabelas menores.

Vai listar clientes, ou fazer um browse, com os campos código, nome, endereço.
NÃO precisa trazer a tabela inteira dos clientes, é só pedir em SQL pra gerar uma tabela menor, é nisso que ele é bom.
SELECT CODIGO,NOME,ENDERECO FROM CLIENTES

Vai listar clientes de SP, idem, pedir em SQL pra gerar uma tabela menor
SELECT CODIGO,NOME,ENDERECO FROM CLIENTES WHERE UF='SP'

Vai listar total de vendas.... só pedir pro SQL gerar uma tabela só com os totais.
SELECT SUM(VALOR) FROM ...

Pois é...
Operações com tabelas.
Pode até juntar várias, pra gerar outra menor.

Se tem que fazer alguma coisa com as tabelas... deixa pro SQL fazer, e ele entregar pronto.

Agora é só imaginar que o SQL poderia somar, dividir, multiplicar tabelas, e nosso trabalho é dizer pra ele a melhor forma de fazer isso, trazendo o máximo que precisamos, com o mínimo de pesquisa.
Se pra isso precisa SELECT de SELECT, tudo bem, se for pra reduzir quantidade de informação pesquisada, podemos aumentar o tamanho do comando à vontade.

É legal isso também, pra comparar com DBFs.

Em DBFs você só trás o que tem em DBF.
Em SQL, você trás qualquer tabela, existindo pronta em DBF ou não.
Justamente isso é o que dá vantagens: você tem infinitas tabelas, basta dizer como é a tabela que está precisando.
Pode ser até uma simples tabela contendo toda informação de cadastro de um único cliente.
Pode ser até uma tabela com um simples código.
Tanto faz, é pedir uma tabela e receber de volta, com tudo que precisa.
Se pedir tudo vém tudo, mas depois não adianta reclamar que demorou demais, porque pediu até o que não precisava.

É simples assim: pede o que precisa, e vai receber o que precisa.

Aqui também podemos mostrar a diferença entre ADO, SQLMIX, hbMySQL, etc.

É tudo tabela.
O servidor vai fazer a mesma coisa em todos, conforme o programa pedir.
A diferença entre eles é... o formato e/ou forma de acessar essas tabelas.
No ADO o formato é ADO, no SQLMIX é DBF, no hbMySQL é array.
Comandos enviados ao servidor, ou retornos recebidos pelo terminal, provavelmente tem o mesmo formato, apenas o programa vai tratar diferente.