Migração de Dbf para MariaDb 10.4

[asimoes]

Isso aqui é fantástico, coisa simples

Código: Selecionar todos

   SELECT  
         BOL.apto, bol.nossonum, bol.valor, bol.dtvenc, cad.SACADO, ABS(TIMESTAMPDIFF( DAY, CURDATE(), BOL.DTVENC ) ) AS DIAS_EM_ATRASO 
      FROM  
         BOLETOS BOL  
         INNER JOIN cadastro cad ON cad.APTO = bol.apto
      WHERE  
         ( BOL.DATAPG IS NULL OR  
         BOL.PAGO = 'N' ) AND  
         BOL.COBRANCA = 'T' -- AND  
         -- BOL.DtVenc <= '2020-03-20' and
         -- BOL.DtVenc <> '2020-03-20'
      ORDER BY  
         BOL.APTO, BOL.dtvenc desc  

[Itamar M. Lins Jr.]

Ola!

bom não vou convencer ninguém aqui, mas é para fazer pensar.

Não tenho dúvidas da superioridade dos SGBDs frente ao DBF. Pq os SGBD's estão evoluindo, o DBF é o que é e pronto.
O DBF do Harbour ainda tem campo incremental, blob... Mas não tem sintaxe SQL, nem servidor, o LetoDbf é um projeto a parte.
Esses outros PAGOS(ADS), é para manter seus clientes, pq não compensa financeiramente mudar.

Saudações,
Itamar M. Lins Jr.

[bencz]

Os SGBD são muito bonitos e tem um bom desempenho, mas...... isso também depende do programador que criou as querys...
o SGBD não faz milagre... se a sua query for mal feita, o sistema vai continuar lento...
Então, antes de colocar a query no programa, utilize um profiler para verificar o desempenho da sua query, veja se está faltando indexes e etc....
Eu utilizo um padrão para os meus sistemas, querys que demorem mais do que meio segundo para retornar, tem coisa errada...

claro que, não irei colocar em um programa um:

Código: Selecionar todos

SELECT COUNT(*) FROM TABELA_GIGANTE_COM_BILHOES_DE_REGISTROS

Em um programa...., como em um programa que vai rodar processos comerciais, esse tipo de coisa não existe ( assim eu acho )....
E, se for necessário fazer algo do tipo, utilizo uma outra estrategia... apenas uso a contagem de elementos do índice da tabela, que retorna instantaneamente....

Um exemplo, tanto eu quanto o Sr. José Quintas, possuímos em um banco de dados os dados abertos dos CNPJs... é aproximadamente 40 milhões de registros....
Operar uma tabela desse porte não é algo simples... os índices nas tabelas tem que estar MUITO, mas MUITO BEM FEITOS!!!!, coisas que podem enforcar o SGBD nesses casos é:

Código: Selecionar todos

SELECT * FROM TABELA_DE_CNPJS WHERE NomeDaEmpresa LIKE '%PLS%'

Se o seus sistema necessitar de algo do tipo, utilize um tipo de índice especifico para busca de texto... no caso do MS-SQL server, esse índice se chama FullText Search.
Query com LIKE são muito perigosas.... é sempre bom tomar muito cuidado com isso, quanto mais profunda for a sua tabela, mais tempo o resultado vai demorar para chegar...

Os indices, tem que ser planejados inclusive para os JOINS!!!!
Então, MUITO cuidado ao desenvolver as querys, para não enforcar o seu sistema em um futuro, quando as tabelas estiverem mais recheadas....

[asimoes]

A minha estratégia é: tabelas até 1000 registros pode ser com selec * ou filtro, acima disso somente com filtro e todos inner joins e filtros utilizo indices

[fladimir]

E com relação a tabelas temporárias?

Exemplo eu pra vender crio uma tabela temporária física e vou carregando ela com os itens (produtos) escolhidos pra venda e as respectivas quantidades e valores etc...
Ao final do processo pego o q esta na tabela temporaria e faço os procedimentos de baixa de estoque (na tabela do sistema produtos) e demais tabelas necessárias e após tudo ok excluo a tabela temporária.

Se no meio do processo der algum problema (fechou sistema, desligou servidor, qualquer coisa) ao entrar pra vender recupera os dados pq ve q tem uma tabela temporaria, ou seja, pendente e importa os dados ou exclui pra começar nova venda zerado.

Como seria isso com SQL/Banco de Dados?

[bencz]

uma tabela com o "header", por exemplo, "VENDAS_HEADER" da venda, que contem os detalhes como, numero do pedido ou algo do tipo, e uma coluna que será um a flag, tipo, "processo finalizado" ( .t. ou .f. )
e você tera uma tabela chamada "VENDAS_DETALHES" que é relacioada com a "VENDAS_HEADER"... ao iniciar, faz um select na tabela VENDAS_HEADER onde a flag == .F.

tipo:

Código: Selecionar todos

SELECT
    VEN_DET.*
FROM VENDAS_DETALHES VEN_DET
INNER JOIN VENDAS_HEADER VEN_HED ON(VEN_HED.ID_VENDA = VEN_DET.ID_HEADER)
WHERE VEN_HED.PROCESSO_FINALIZADO = FALSE

[fladimir]

Obrigado pela resposta
Deixa ver se eu entendi.

Vc diz ao invés de eu ter uma tabela temporaria (q é como faço hj, crio um DBF, uso, depois apago)
Ter uma tabela fixa no banco e controlar ela via FLAG, seria tipo uma tabela de apoio?
Via banco não existe o conceito de tabela temporaria q possa-se criar, usar e depois apagar?

Pq hj eu tenho 1 tabela chamada Vendas e outra VendasItem, q é tipo o q vc sugeriu Header e Detalhes (Pai e filho digamos assim) porém essas tabelas eu só alimento depois q eu concluo a venda temporaria (tabelas temporarias)

[asimoes]

Obrigado pela resposta
Deixa ver se eu entendi.

Trabalha com hashtable, ou dbf temporário, na minha opinião é desnecessário criar tabela temporária no BD, use os recursos que o harbour oferece eu faço assim.

[JoséQuintas]

E com relação a tabelas temporárias?
Exemplo eu pra vender crio uma tabela temporária física e vou carregando ela com os itens (produtos) escolhidos pra venda e as respectivas quantidades e valores etc...
Ao final do processo pego o q esta na tabela temporaria e faço os procedimentos de baixa de estoque (na tabela do sistema produtos) e demais tabelas necessárias e após tudo ok excluo a tabela temporária.
Se no meio do processo der algum problema (fechou sistema, desligou servidor, qualquer coisa) ao entrar pra vender recupera os dados pq ve q tem uma tabela temporaria, ou seja, pendente e importa os dados ou exclui pra começar nova venda zerado.
Como seria isso com SQL/Banco de Dados?

Sei lá.... que coisa mais feia de se fazer.... kkkkkk

Minha digitação de pedidos é livre, o usuário vai digitando e vai salvando.
Vou validando estoque, etc. durante digitação.
Só quando o usuário confirmar o pedido é que faço as atualizações de estoque.
E não deixo confirmar o pedido, se faltar estoque.
ISSO EM DBF.

Em SQL....
Melhor ainda: pode usar transação.
Numa transação, o servidor/banco de dados vai considerar todo o processo.
Se por algum motivo ficar pela metade, ela não é salva, simples assim.

Nota:
E nesse meio tempo, se precisar autorização de outra pessoa pra confirmar sem estoque, ou outras coisas mais, tá tudo lá pra outra pessoa poder autorizar.
No seu caso como seria? não dá?

Nota2:
Se der problema... o pedido tá lá gravado, não mexeu com nada, só vai mexer se confirmar.

[JoséQuintas]

Mesmo se tiver problemas com parte fiscal... tá lá... no aplicativo.
A rotina de confirmação impede que confirme pedido com irregularidade.

Na digitação... é um produto por vez... se acabar a luz... o máximo que o usuário perde é um produto.
E na confirmação... quase não tem o que atualizar... é rápido, quase impossível ter problema.
Nem importa quantos estão digitando pedido ao mesmo tempo.
Faz anos que uso assim, sem problemas, nem mesmo em redes mais "porcarias".

Estou falando de DBF !!!
Se funciona em DBF, em SQL vai funcionar melhor ainda.

[JoséQuintas]

Também tem outra:

STORED PROCEDURE.

Pode criar uma rotina de atualização no próprio servidor.
Acabou de digitar o pedido, chama essa rotina, sendo no servidor, nem acabar luz não vai impedir a atualização.

[JoséQuintas]

Veja bem:

Vai digitando produtos e vai salvando.... um registro por vez.
Confirmou... de um modo geral é atualizar estoque e alterar o status do pedido.

Do seu jeito:
Vai ter processamento adoidado, pra salvar muitos produtos, atualizar estoque, etc.

Qual dos dois jeitos acha que pode causar mais problema de índice, ou atualização incompleta?

[Itamar M. Lins Jr.]

Ola!
Quintas, não vi diferença no processo do Fladimir.
Um arquivo que fica em "Stand by".
Eu faço da mesma forma que vcs. Só podemos baixar do estoque depois da confirmação.
No caso a confirmação é o pagamento. E vai para gerar a NFCe. E ainda tem pedidos confirmados que vai para outra área gerar NFe.
Não sei com irei fazer usando SQL.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Quintas, não vi diferença no processo do Fladimir.
Um arquivo que fica em "Stand by"

Eu não uso arquivo temporário.
Eu gravo direto.
O pedido pode estar confirmado ou não, pode estar em digitação ou não.
Ao confirmar, faz só o processo de baixa/etc, e altera o status do pedido.

Se usa um temporário separado do restante, vai ter que gravar tudo que o usuário digitou, e também atualizar.

[Itamar M. Lins Jr.]

Ola!
Entendi.
Assim é pq vc está usando "fila indiana".
No caso do atendimento com balcão farmácias e mat. de construção, iria ficar cheio de pedidos sem confirmação e orçamentos...
Tem muito pedido refeito, tira um dois itens... Faz orçamento e depois volta para comprar.
Tem muita coisa que só vai gravado quando o cliente confirma. O principal é a "quantidade, codigo, desconto, nome cliente"

Saudações,
Itamar M. Lins Jr.