SQL e DBASE

[JoséQuintas]

Uma coisa curiosa nestes dias, ao mostrar SQL para um colega, usando o dBase como exemplo.

Como funciona o SQL:
O micro envia o pedido:
SELECT * FROM CLIENTES WHERE UF='SP'
E o servidor retorna a lista de clientes com UF SP.

o dBase (ou Foxbase ou Foxpro DOS):
Nele, ao carregar aparece lá o prompt. Do mesmo jeito que tem o prompt do DOS, tem lá o prompt do dBase.
Nesse prompt, podemos digitar.
USE CLIENTES
LIST FOR UF='SP'
E aparece na tela a lista de clientes com UF SP.

Comparando os dois, vejam que interessante:
É como se os comandos do programa fossem a digitação no prompt do dBase.
E o retorno do SQL, como se fosse o retorno da tela do dBase.
Ou, como se o dBase rodasse no servidor, e cada terminal tendo seu próprio prompt, via programa.

Achei interessante isso.
O SQL acaba parecendo só um dBase melhorado, passando recursos do prompt para o programa.
Estou falando somente dessa comparação de comandos, e essa comunicação básica.
Por trás disso, muita coisa ficou diferente.
Mas essa parte básica... é curioso como se parecem.
Não sei se mais alguém já tinha olhado por este lado.

[JAIR RANGEL]

OLÁ, JOSÉ !

Sim. Eu já havia percebido esta semelhança. Mesmo que ainda não tenha feito a implementação do SQL em meus programas, mas revirando literaturas e tudo que consegui sobre SQL, percebi esta incrível semelhança.
So da época do DBASE.
Portanto, não tem como não perceber. Claro q muita coisa mudou. Mas as vezes chego a pensar q o que mudou foi somente o nome dos comandos.

Vlw

[Maligno]

Olhando por esse ângulo, é verdade. Visualmente se parecem. Acho que no meio dessas centenas de outras linguagens de programação (provavelmente algumas até derivadas do XBase - ou que delas ele próprio foi derivado) que existem por aí, deve ter alguma outra também semelhante. Até porque, é coisa bem simples, fácil de entender, amigável. Por isso, atraente.

Mas só de lembrar que no XBase a tabela toda tem de trafegar pela rede para passar pelo filtro montado, dá gosto saber que nos SGBD modernos tudo acontece lá no servidor. Uma otimização e tanto. Em nível de velocidade e segurança.

[LordJonas]

Boas.

Na realidade, comparando a evolução do SQL desde o tempo do dBase até aos sistemas actuais de Banco de Dados, a grande mudança não teve a ver com a linguagem usada para se obter o output desejado, mas mais com o ODS (On-Disk Structure) que tornou obsoletos muitos banco de dados antigos devido a problemas de incompatibilidade.

Os comando mantiveram-se praticamente os mesmo ao longo dos anos com algumas ligeiras adaptações e implementações de extensões por este ou aquele fabricante de software.



Não admira pois que neste últimos 10 a 15 anos tenhamos visto sugerir novos produtos no mercado desde soluções Open-Source (MySQL, Firebird, Postgres, Oracle) até soluções comerciais, graficamente mais apelativas e com suporte técnico supostamente melhor.

Mas sejamos realistas: o "core" de todas elas permaneceu imaculado desde os velhos tempos do dBase IV, sendo que a grande alteração foi a possibilidade de suportar um maior número de tabelas e campos e uma capacidade de armazenamento em disco praticamente ilimitada.

)

Por isso quem como eu, e mtos companheiros aqui no fórum, usava o prompt do dBase IV para fazer as suas queries, reports, etc... apenas tem de se habituar a traduzir essa "harcore" maneira numa mais gráfica utilizando as ferramentas agora disponíveis.

:%

Abraço.

[alxsts]

Olá!

Lendo o tópico, tive a impressão que o dBase nasceu antes do SQL e o SQL foi inspirado no dBase... Só que o modelo da linguagem SQL foi proposto em 1970 pelo Dr. Edgar F. Codd e o primeiro banco de dados relacional (Ingres) surgiu em meados dos anos 70. Já o dBase apareceu no início dos anos 80.

[LordJonas]

Olá.

O companheiro alxsts tem toda a razão nesse ponto. No entanto, tendo em vista que neste fórum dedicado ao Clipper e suas variantes o modelo mais utilizado na década de 80 foi o dBase, não podíamos deixar de o mencionar por isso mesmo.

Quem nunca utilizou o dBase que dé uma passo atrás...

)

[Maligno]

Bom, que se diga: a semelhança entre as linguagens é pequena. A linguagem SQL, obviamente, tem muitos recursos a mais e, claro, uma linguagem mais "parruda". Agora, a semelhança é só essa. O "core", ou seja, a máquina de administração dos dados, se é que posso chamar assim, é estrondosamente diferente. O dBase nem passa perto da filosofia de um SGBD. Pudera: parou no tempo.

[JAIR RANGEL]

Boa tarde, senhores !

Estou precisando de um pouco de ajuda no que se refere a escolher uma alternativa de implementar o MySQL nos meus programas:
Confesso estar um pouco perdido, pois as alternativas de como fazer isto ou aquilo são diversas.

BEM, DEIXE EU ESCLARECER A MINHA CONFIGURAÇÃO ATUAL:
Sistemas Rodando: ERP (Vendas,Estoque,Pagar,Receber,...,...)
Arquivos: DBF/CDX.
Linguagem: MiniGUI/Harbour - 2004 / 2005 Roberto Lopez - Atualização 17/05/2005.

Senhores, todos os módulos funcionan redondos !!!

AGORA, AS MINHAS CONFUSÕES A RESPEITO DAS ALTERNATIVAS:

1 - Atualizar a MiniGUI/Harbour para Versões 2.xx, 3.xx, para utilizar o ADORDB:
O Compilar mudou para Mingw, o que me gera uma série de dúvidas. Esta mudança é uma boa: Tudo será compatível com o que já fiz até hoje:
Caso venha a atualizar, vou mandar ver no ADORDB, deste modo, vou ter que reescrever todas as rotinas de leitura e gravação dos Arquivos:

2 - Poderia utilizar o SQLLIB do Sr. Vailton (mesmo pago), mas caso eu faça isto, acredito que não poderei migrar a MiniGUI/Harbour para versões atuais, pois, o compilador Mingw, não irá reconhecer a SQLLIB. Me corrija se estiver errado.

3 - Poderia, também, optar por utilizar o SQLLIB e passar a utilizar a versão que dizem EXPERIMENTAL da MiniGUI/Harbour (que não tem nada a haver com o Roberto Lopez). Porém, verifiquei o MiniGUI/Harbour 3.xx está evoluindo muito. Falam até em Linguagem multiplataforma. Achei muito legal isto. E ai, vale a pena abandonar a Versão do Sr. Roberto Lopez:

4 - Mediator - Falam muito deste Mediator - Mas acredito estar no mesmo dilema do SQLLIB. E mais, me parece que o Mediator tem que estar instalado junto ao Banco de Dados e nas estações de trabalho. Sei não....fico meio cabreiro de utilizar este programa, exigindo muito trabalho braçal de configuração para implantar.

Me desculpem todo este roteiro de dilemas e dúvidas. Mas se não recorrer a voces aqui do Forum, não tenho mais a quem discutir estes meus Fantasmas. Quero sim, atualizar meus Programas. Utilizar MySQL, instalar versões atuais da MiniGUI/Harbour. Mas decidir isto sozinho tá dificil.........

Se alguem se arriscar nas respostas, um muito obrigado !

JAIR RANGEL
jairrangel@uol.com.br
legnarinfo@hotmail.com
www.admsmart.com.br
(21)2413-5440
(21)7866-0691
ID: 10*29501
MSN: legnarinfo@hotmail.com
ADM SMART - Programa de Automação Comercial
(MINIGUI/HARBOUR/BRMAKE/DBF/CDX)

[JoséQuintas]

Não uso harbour/xharbour, então só vou acrescentar mais uma opção à sua lista:

O que imagino, para ter pouco trabalho:
- Compilar Minigui com xHarbour (pelos textos parece ser possível)
- Usar RddSQL (pelos textos, a alteração de fonte é mínima, apenas na abertura de arquivos)
A partir daí, já com o sistema rodando em MySql, verificar possibilidades de otimizações.

Agora falta alguém passar o lado prático das opções, pra saber qual funciona direito.

[JAIR RANGEL]

Olá, JoséQuintas !

Obrigado pela dica.
Fica ai mais uma para povoar minhas alternativas.
Quando se refere a RddSQL, acredito estar falando em SqlLib ou Mediator. Me corrija se estiver errado.
Quanto ao utilizar xHarbour: Porque a dica de utilizar o xHarbour:

Obrigado por responder !

JAIR RANGEL

[JoséQuintas]

Além dos componentes que fazem parte do xHarbour, tem o componente comercial RDDSQL.
Este componente, tem uma versão paga que pode ser usada com o xHarbour free.
Como só tem disponível para o xHarbour, por isso falei dele.
A informação sobre a RDDSQL pode ser encontrada aqui:
http://www.xharbour.com.br/sqlrdd.html

Promete migração com trabalho quase zero.
Como eu disse antes, só mostrando opções, mas precisa confirmar com quem usa ou já usou.

[JAIR RANGEL]

Olá, José Quintas !

Valeu pelas dicas.
Vou continuar as pesquisas. O que eu decidir vou postar aqui !

Um abraço !

[clrod]

Olá

Em primeiro lugar quero dizer que há alguma confusões com a comparação da linguagem xBase com SQL. Concordo com o maligno que as linguagens até se parecem, até porque o Vulcan/dBase foi criado para ser uma simplificação do SQL. Mas o core, ou seja a forma interna como as coisas são tratadas, forma de armazenamento, forma de acesso em leitura ou escrita, segurança, garantias oferecidas, etc pelos DBs que seguem os padrões SQL são absolutamente incomparáveis e nem estou dizendo que é para melhor ou pior, embora em quase todos os aspectos seja para melhor. A semelhança pára na forma como se escreve uma query básica, mas não passa perto como essa query é executada.

Tentendo ajudar o amigo JAIR RANGEL eu diria:

1 - Atualizar a MiniGUI/Harbour para Versões 2.xx, 3.xx, para utilizar o ADORDB:
O Compilar mudou para Mingw, o que me gera uma série de dúvidas. Esta mudança é uma boa: Tudo será compatível com o que já fiz até hoje:
Caso venha a atualizar, vou mandar ver no ADORDB, deste modo, vou ter que reescrever todas as rotinas de leitura e gravação dos Arquivos:

O ADORDD pode ser uma boa solução intermediária de migração, longe de ser perfeita, mas é uma boa. Apenas não use isso como solução definitiva. Em definitivo você deve usar o modelo SQL real de acesso aos dados. Não se preocupe como o MingW, o Harbour é feito para funciona igual em todos os compiladores (sempre que possível). O MingW é o compilador de referência do Harbour e é o mais compatível de todos. Vá sem medo. Inclusive o Roberto está baseando a MiniGUI 4 na HBQt o que considero a melhor decisão que ele tomou desde a criação da MiniGUI.

2 - Poderia utilizar o SQLLIB do Sr. Vailton (mesmo pago), mas caso eu faça isto, acredito que não poderei migrar a MiniGUI/Harbour para versões atuais, pois, o compilador Mingw, não irá reconhecer a SQLLIB. Me corrija se estiver errado.

Converse como o Vailton sobre isso. Ele é bem aberto a sugestões. A SQLLib talvez possa ser a melhor opção para sua migração.

3 - Poderia, também, optar por utilizar o SQLLIB e passar a utilizar a versão que dizem EXPERIMENTAL da MiniGUI/Harbour (que não tem nada a haver com o Roberto Lopez). Porém, verifiquei o MiniGUI/Harbour 3.xx está evoluindo muito. Falam até em Linguagem multiplataforma. Achei muito legal isto. E ai, vale a pena abandonar a Versão do Sr. Roberto Lopez:

Eu particularmente prefiro usar a HBQt direto, mas para o clippeiro típico, a MiniGUI me parece ser a melhor opção, principalmente com as novidades da versão 4 que corrige vários problemas que pareciam insolúveis (alguns era pura teimosia, mas parece q ele está cedendo sem deixar transparecer muito).

4 - Mediator - Falam muito deste Mediator - Mas acredito estar no mesmo dilema do SQLLIB. E mais, me parece que o Mediator tem que estar instalado junto ao Banco de Dados e nas estações de trabalho. Sei não....fico meio cabreiro de utilizar este programa, exigindo muito trabalho braçal de configuração para implantar.

Outra razoável opção intermediária. Não sei se seria a melhor para você, mas funciona bem e não dá tanto trabalho. Acho uma solução um pouco limitada e mais gambiarra que outras opções.

O mais importante é que você está querendo evoluir e me parece estar fazendo seu dever de casa. Só ressalto que para a migração ser completo, em algum momento você deverá, migrar o modelo de acesso dos seus dados para SQL e abandonar o modelo de RDD. Claro que dá para ter sucesso com o modelo intermediário, mas ele é uma gambiarra e me parece que você quer uma evolução real, portante use um RDD apenas como tranbsição para o modelo adequado.

Por fim, evite o SQLRDD e o xHarbour. Sair do Harbour para ir para o xHarbour é um retrocesso só melhor que voltar para o Clipper O fato de funcionar não é bom argumento para medir qualidade, se fosse assim, todos usaríamos o Clipper ainda, porque ele continua funcionando.

Evidentemente não vou impor nenhuma solução para ninguém, mas essa é minha opinião sobre o assunto e particularmente eu uso o acesso nativo ao MySQL fornecido pelo Harbour. Por um curto período usei o ADORDD mas nunca foi colocado em produção. Foi apenas para testar as modificações que eram feitas.

T+

[Stanis Luksys]

Hehehe,

Este fórum nunca muda e sempre temos excelentes discussões, por isso gosto tanto dele!

Para inciar, como eu sou daqueles que não medem esforços quando o assunto é programação, gosto mesmo de entrar nos códigos, para mim, a melhor opção é usar as libs nativas do xHarbour e escreber cada query na unha. Mas é claro que exige mais tempo, e essa é uma opinião baseada em gosto pessoal, e não significa que eu esmo não adote outras, afinal prazo é prazo. Ja testei todas as opções acima e implementei o mediator em grande escala num escritório, alguns anos atrás. Ficou bom!!!!

Mas... não recomendo, é muita gambi por tras dos processos. A manutenção direta no banco, que nós sabemos é necessária quando em vez, é dificilima no mediator, por que ele monta a estrtura no banco, de acordo com os padrões dbase, criando uma espécie de índices falsos etc. Ou seja, se você dá um patada de urso direto no banco, desatualiza os índices que o sistema usa através do Med.

Se tudo ainda fosse fácil como era no dbase e no xbase, o mundo seria melhor... Hoje é praticamente impossível programar numa linguagem sem tem que ter boas noções em mais umas outras duas ou três! A curva de aprendizado é bem maior.

Acho que a grande sacada dos SGDBs, além das já apontadas, como centralizar as operações no servidor e diminuir o tráfego, foi o fato de permitir as famosas stored procedures, triggers etc e tal.

Isso nos da a possibilidade de realizar controles de banco numa camada mais baixa, independente do software que o acesse.

Seria como ter um programa em clipper que não permite exclusão de usuário nunca, apenas marca como inativo. Aí o espertão vem pelo lado do cliente, e mesmo sem acesso ao servidor, apaga os registros pelo dbase, dbu ou seja o que for. Isso não aconteceria nos DBs modernos, porque o próprio banco tem condições de barrar.

Isso ainda sem contar o controle de acesso por usuário, que antes não existia. Em termos de sintaxe é bem parecido mesmo, mas as exigências por performance e eu diria que principalmente por segurança, tanto dos dados como contra invasores piratas, fpoi determinante na forma como foram concebidos esses BDs da nova geração.

Abração!

[JAIR RANGEL]

Olá, Senhores !

Confesso que estou maravilhado tal os depoimentos com altíssimo grau de conhecimento sobre o assunto.
Me sinto lisonjeado por, humildemente, participar deste forum.
Sou da época do DBASE I,II, etc...
Me amarro entrar no Dbase, hoje, as vezes, utilizo o FoxPro25, e digitar aqueles comandos no prompt.
A resposta é sempre a jato.
Faço uma analogia com os comandos SQL.
Por isto, também concordo que seria muito interessante arregaçar as mangas e partir para uma migração de contato direto com o SGBD. O escolhido: MySQL.
Lógico, tenho muito o que aprender sobre o assunto.
Mas gosto de uma boa briga. Excelente desafio e conhecimento nunca é demais.
Quanto ao tempo para a migração nativa, vai rolar no tempo que tiver que ser.

Preciso fazer uma pergunta técnica: Me perdoem a inocência na questão.

Ao utilizar acesso nativo ao Banco de Dados (comandos SQL que serão digitados dentro do código) terei que utilizar nas tabelas os ÍNDICES de acesso:
Ou tudo que eu quiser ler no Banco será atraves de comandos: Ex: Select * From....

Pois, tenho um livro aqui de MySQL que diz que posso utilizar indices para agilizar as consultas.
Se for assim, então, é bem semelhante ao DBF.
Após converter um DBF para Tabela MySQL, vou gerar os índices. Tal qual faço nos DBFs.

Desde já, obrigado a todos pela atenção !

Jair Rangel
Harbour+MiniGUI+BrMake+BCC