PC Toledo

Tem várias opções. Vamos ao MySql como exemplo:

O MySql fornece uma DLL de acesso. Essa DLL tem funções prontas, chamadas de API.
O programa simplesmente usa essas funções, sem precisar linqueditar junto ao programa, basta estar lá instalada no micro.

Usando um código fictício, usando as funções da DLL, que alguns chamam de acesso nativo, poderia ser algo assim:
Ou um pouco de sql, ainda com APIs:
Ou o ADO da Microsoft, que sou fã:
No geral, acho muito mais vantajoso usar direto comandos SQL, mas a escolha é do programador sobre como vai usar, e também dos recursos da linguagem, que geralmente tem até mais opções.
Como exemplo, o xHarbour faz uso da DLL do MySql, mas tem suas funções próprias de "tradução", pra aproveitar a sintaxe xbase.

Outro exemplo de tradutor é justamente o ADO, cuja intenção foi tornar transparente ao programador sobre qual banco de dados está usando, e até mesmo semelhante em qualquer linguagem.

Resumindo: é o programador que escolhe a forma de trabalhar

Agora, sinceramente, eu ainda estou fazendo pouco uso da base MySql.
Mas esse pouco uso já está dando ótimos resultados práticos, há bastante tempo.

Olá

Banco de dados não inventa muita coisa nos fundamentos, então índices são importantes em qualquer SGDB. Basicamente pode se transpor os mesmos índices do DBF para um SGDB SQL (não os arquivos claro, apenas o mesmo modelo).

Apesar disso funcionar bem, existem situações em que os índices devem ser adaptados para uma melhor performance. O modelo mental de usar DBF é diferente do SQL e nem tudo o que funciona bem no DBF funcionará tão bem em SQL, aí é preciso fazer um pouco de profiling e tunar o banco de dados para atender melhor as necessidades. Claro que funcionar, funciona do jeito básico.

Uma das coisas que iniciantes em SQL podem ter dificuldade é que não há acesso direto ao número do registro em SQL. A técnica básica quando isso for necessário é criar uma coluna (campo) chamada ID (pode ter outro nome, mas esse é o padrão). Normalmente essa coluna não aceita NULL, é UNIQUE e tem um índice associado a ele para o acesso direto rápido. Em geral só se cria a coluna ID quando a tabela é acessada por outras tabelas através de uma chave estrangeira. Ex.:

tabela Clientes
colunas ID, código, nome, etc

tabela NFs
colunas ID, número, série, clienteID, etc

Essa coluna clienteID faz referência a uma linha (registro) da tabela Clientes e acho ser óbvio que é uma referência à coluna ID de Clientes, ou como se costuma escrever, ao Clientes.ID

Em geral o clippeiro típico usa o próprio código do cliente como chave estrangeira. Embora isso funcione é mais recomendável a utilização do ID que é independente do código usado.

Inclusive tenho clientes que sequer usam o campo Código, acessam pelo Nome sempre. Claro que internamente o sistema faz o acesso pelo ID.

Esse é só um exemplo da mudança de mentalidade que precisa ser feita, tem outros até mais importantes.

Aproveito para colocar um link para uma página de comparação da sintaxe do xBase com SQL (em inglês): http://www.dbase.com/Knowledgebase/INT/ ... /x2sql.htm

Espero ter ajudado.

T+

Uma das coisas que iniciantes em SQL podem ter dificuldade é que não há acesso direto ao número do registro em SQL

Discordo, porque o número de registro é o que menos importa, até mesmo no clipper.

Normalmente essa coluna não aceita NULL, é UNIQUE

Também discordo, porque faltou justamente o mais importante.
No SQL existe um campo incremental/autonumeração, onde o próprio SQL vai colocando o número automaticamente.
Ao definir como incremental, ele já é definico como único (sem repetição), e pra não ficar vazio (NULL).

Inclusive tenho clientes que sequer usam o campo Código, acessam pelo Nome sempre. Claro que internamente o sistema faz o acesso pelo ID.
Esse é só um exemplo da mudança de mentalidade que precisa ser feita, tem outros até mais importantes.

Usar por código ou por nome, isso é opcional, nada tem a ver com base SQL.

A vantagem do SQL é que "ele toma conta dele mesmo".
E ele faz o trabalho pesado no banco de dados, liberando serviço do programa e terminal.
Também dá pra configurar lá na base de dados pra, por exemplo, não aceitar cadastrar fatura de cliente que não existe, ou não aceitar fatura de valor zero.
Mesmo que o programador tente fazer via programa, o SQL não irá permitir isso (desde que a base esteja configurada assim).
Este sim, é um bom exemplo do que podemos ter a mais.
O programa poderia simplesmente mandar gravar a fatura, e pegar a resposta do servidor, que avisará sobre cliente não cadastrado ou valor zerado.

De qualquer forma, tudo tem limites, então na prática vai ajustando conforme as necessidades.
Quando falo em limites, é tipo criar um campo que é resultado de uma pesquisa.
Aí o acesso a esse campo várias vezes vai executar pesquisa várias vezes.
Tudo é questão de começar a usar, e ir acrescentando o que tem disponível, e avaliando resultados.
Ou seja, nada diferente do nosso dia a dia.

Discordo, porque o número de registro é o que menos importa, até mesmo no clipper.

Eu não vou fazer um tutorial porque isso é importante, mas basta ver que é utilizado por todo programador que tem sólidas bases em banco de dados.

A maioria dos clippeiros só sabe fazer acesso por índice e ignora as vantagens de acessar pelo número do registro ou acha difícil fazer desta forma já que é preciso tomar alguns cuidados, apesar da enorme vantagem que isso oferece onde é pertinente.

Quem tem dúvida sobre isso eu aconselho pegar livros e revistas especializadas além de pegar bons modelos de bases disponíveis como exemplos de boas práticas e ver com os próprios olhos.

Todo mundo tem o direito de fazer como quiser, mas é muito melhor poder escolher a melhor forma e não fazer da única forma que sabe fazer. Eu acho que uma das maiores vantagens de migrar para SQL é aprender um novo modelo mental para banco de dados e utilizar esse modelo adequadamente, mas admito que é mais cômodo manter o mesmo modelo de antes.

Também discordo, porque faltou justamente o mais importante.
No SQL existe um campo incremental/autonumeração, onde o próprio SQL vai colocando o número automaticamente.
Ao definir como incremental, ele já é definico como único (sem repetição), e pra não ficar vazio (NULL).

Como eu falei genericamente e nem todo DB tem auto incremento, então a informação é válida, você apenas acrecentou algo que também é importante.

Usar por código ou por nome, isso é opcional, nada tem a ver com base SQL.

E em que parte do que foi cotado está dizendo que tem haver com SQL? De qualquer forma, se fosse cotado tudo o que escrevi sobre ID, ficaria mais fácil de entender. É fácil discordar quando se tira do contexto.

A vantagem do SQL é que "ele toma conta dele mesmo".
E ele faz o trabalho pesado no banco de dados, liberando serviço do programa e terminal.

Essa não é a definição do que é SQL, você definiu basicamente o que é cliente/servidor. Um ADS e parcialmente um LetoDB pode fazer isso sem ser SQL, existem diversos outros exemplos de banco de dados que não são SQL e que permitem um controle completo do acesso. Tem DBS SQL que não liberam serviço do programa/termninal. Tem bancos baseados em SQL que não possuem uma série de constraints para "tomar conta" do DB. Pode até não estar seguindo o SQL ANSI, mas segue o modelo SQL que todo mundo conhece.

Como eu disse, é um erro comum de quem vem do Clipper achar que é a mesma coisa, eu diria que 95 à 99% dos clippeiros acham que é a mesma coisa e nem sabem o quanto estão subutilizando a nova ferramenta. É a velha argumentação "está funcionando então está certo".

É óbvio que dá para usar o modelo mental de DBF em um banco de dados baseado em SQL, existem inúmeros casos de *relativo* sucesso, mas é uma gambiarra e o sucesso é muito maior quando se adota o modelo mental apropriado para a tecnologia.

Talvez o que melhor definição a diferença é a ausência de navegação direta no banco de dados como se faz normalmente no DBF. Qualquer um pode achar que é a mesma coisa, mas não é e grande parte da eficiência do SQL se perde desta forma.

O meu conselho para quem quer evoluir na utilização de banco de dados é se aprofundar no novo modelo adotado por DBs baseados em SQL, mas também dá certo continuar adotando as mesmas práticas de sempre e se manter com visão única de como fazer as coisas.

Eu sempre prefiro estudar o que vou fazer e repudio qualquer forma de tentativa e erro. Mas cada um pode fazer sua opção.

T+

Eu imagino o seguinte:
Quem vai mudar pra outra base de dados quer se sentir tranquilo na migração.
Então precisa saber da parte que atende suas necessidades, pra saber que pode ir.
Os outros recursos existem, são ótimos, mas está mostrando como se fosse algo obrigatório.

Até mesmo o número de registro que existe no Clipper, mostrou como se fizesse uma grande falta.

Pra mim é o seguinte:
O principal é mudar de base de dados, esteja sub-utilizando ou não.
Uma vez familiarizado com a nova base, está livre pra brincar à vontade, e implementar novos recursos.
E vai fazer tudo com muito mais tranquilidade.
Se começar querendo usar a parte avançada, e algo der errado, pode não saber avaliar se o problema foi a base ou sua programação.

Fora que tem uns grandes ERPs que enchem o banco de tanto relacionamento e validação, que qualquer operação fica lenta, exigindo um servidor extremamente potente para fazer coisas simples como consultas.

Só acho que não deve ser mostrado como obrigatório, apesar que a maioria já deve conhecer algum SQL.

Olá

Por isso em nenhum momento eu coloquei que era obrigatório, lendo o primeiro e segundo parágrafos, fica claro que dá para migrar sem problemas ou maiores adaptações e que opcionalmente pode se fazer melhor conforme indica o trecho "devem ser adaptados para uma melhor performance", ou seja, só para quem quer melhor performance.

T+

Uma das coisas que iniciantes em SQL podem ter dificuldade é que não há acesso direto ao número do registro em SQL....

Este texto me deu a impressão de que o número de registro faz falta.

Minha história:

Tenho uma base MySql há muitos anos.
Começou guardando apenas as consultas de CEPs, que meu sistema faz nos correios.
Extremamente sub-utilizada.

Depois também começou a salvar as Notas Fiscais Eletrônicas.
Tem todas as notas emitidas e recebidas desde abril/2008 de todos os clientes.
Extremamente sub-utilizada.

Depois alguns módulos que deixaram de existir no Clipper, e só tem em VB/MySql.

Resumindo: Estou usando MySql sim, estou sub-utilizando MySql e recursos sim, boa parte do sistema continua em DBFs sim, mas o importante é: já estou tirando proveito de tudo isso, e um pouquinho mais a cada dia. E não precisei converter todo o sistema de uma vez, bastou começar a usar.

O único lado ruim da base na internet é no backup completo.
Baixar centenas de megas demora.
Apesar do meu servidor fazendo backup a cada novo lançamento, pelo menos uma vez por semana baixo um backup completo.
Até hoje não precisei, mas nunca se sabe...

Olá

Cada um pode ter a impressão que quiser, eu não disse que faz falta.

De qualquer forma, para a minha metodologia que é amplamente adotada fora do mundo xBase, sem o ID complica a organização do banco de dados, manutenção futura e performance.

Quando trabalhava com DBF eu usava pencas de DbGoto que é muito mais eficiente para estabelecer relacionamento de tabelas do que DdSeek e absurdamente melhor que usar Set Relation. Claro que essa não é a metodologia mais fácil, é a mais eficiente.

Sua história confirma tudo o que eu disse, dá para fazer a transição aos poucos mas enquanto o modelo mental aprendido e não for trocado, a nova ferramenta será usada com limitação. Nenhum problema com isso, mesmo que a solução intermediária se torne definitiva, apenas não dá para dizer que é eficiente. Eu só tentei mostrar que algumas coisas precisam ser repensadas para aproveitar todo potencial da nova ferramenta.

T+

OLÁ, PESSOAL !

Vocês são EXCELENTES !!!!
Uffa !!!!

:-Y