Dúvida sobre arquivo múltiplo

[JoséQuintas]

Tenho trabalhado com um arquivo que atende diversos cadastros. (DBF).
Pensei em separar cada cadastro em um arquivo diferente, ou usar o mesmo arquivo em ALIAS diferentes e com filtro.
Mas trabalhando com DBFs, não sei se isso seria problema pro Harbour: abertura de arquivos em rede se tornar lenta, usar mesmo arquivo em alias diferentes ter problema de execucão, etc.
Será o aumento de uns 100 arquivos no sistema, ou 200 contando os CDXs.
O que indicam? Deixar como está, ou dividir de uma dessas formas pra não ter problemas com Harbour?

Por enquanto fiz este teste e funciona.
Neste exemplo, jptabel contém as tabelas de cst de icms, ipi, pis e cofins, indicado pelo campo AXTABELA.

Código: Selecionar todos

PROCEDURE Main
   REQUEST SIXCDX
   RddSetDefault( "SIXCDX" )
   SET EXCLUSIVE OFF
   IF .NOT. OpenDatabases( { "jpregra", "jpicmcst", "jpipicst", "jppiscst", "jpcofcst" } )
      QUIT
   ENDIF
   FOR nCont = 1 TO 1000
      SELECT (nCont)
      IF .NOT. Empty( Alias() )
         ? Alias()
      ENDIF
   NEXT
   RETURN NIL   

STATIC FUNCTION OpenDatabases( aFiles )
   LOCAL nCont, lOk := .t.
   
   FOR nCont = 1 To Len( aFiles )
      IF .Not. OpenDbf( aFiles[ nCont ] )
         lOK := .f.
         EXIT
      ENDIF
   NEXT
   RETURN lOk
   
STATIC FUNCTION OpenDbf( cAliasName )
   LOCAL lOk := .t., nSelect
   LOCAL cDbfName := ""
   LOCAL cFilter  := ""
   
   DO CASE
   CASE cAliasName == "jpregra"
      cDbfName := "jpimpos"
      cFilter  := ""
   CASE cAliasName == "jpicmcst"
      cDbfName := "jptabel"
      cFilter := "Val(jpicmcst->axTabela) == 2"
   CASE cAliasName == "jpipicst"
      cDbfName := "jptabel"
      cFilter  := "Val(jpipicst->axTabela) == 7"
   CASE cAliasName == "jppiscst"
      cDbfName := "jptabel"
      cFilter  := "Val(jppiscst->axTabela) == 14"
   CASE cAliasName == "jpcofcst"
      cDbfName := "jptabel"
      cFilter  := "Val(jpcofcst->axTabela) == 16"
   OTHERWISE
      lOk := .f.
   ENDCASE
   IF lOk
      nSelect := Select( cAliasName )
      SELECT ( nSelect )
      USE (cDbfName) ALIAS (cAliasName)
      SET INDEX TO (cDbfName)
      SET FILTER TO &( cFilter )
      GOTO BOTTOM
   ENDIF
   RETURN lOk

[lugab]

José Quintas,

De todos, sou um dos menos qualificado pra opinar, entretanto, como não vou matar ninguém com opinões, afirmo q escolheria trabalhar com várias tabelas, em vez de uma só, pq um "tiliti" no arquivo único de todas as tabelas vai dar muito mais problemas para as recompor do q se der "tiliti" em apenas uma das tabelas, q será recomposta com menos traumas.

E, por experiência própria, em vez de usar "filter " use "setsocpe" que é N vezes mais rápido.

[JoséQuintas]

Já uso assim, multicadastro há alguns anos, sem problema.
A vantagem é que um único programa de cadastro e relatório atende a todas elas de uma vez.
A desvantagem senti no VB6, usando ADS com comandos SQL, que acaba complicando o comando SQL pra trazer os dados.
E além disso, como usa sempre o mesmo arquivo, difícil localizar no fonte se um cadastro deixou de ser usado, por exemplo, já que a única diferença é um código de tabela.

Não sei ao certo, mas supondo que sejam 100 tabelas, separar significa aumentar 100 DBFs, 100 CDXs, 100 programas de cadastro, e alguns programas de relatório (CFOP, CST, etc. por ser do governo não precisariam relatório).

1. Arquivo único: implica em conhecer o código de cada cadastro, dificulta pesquisar o que está em uso em cada fonte, e acaba necessitando código extra pra isolar cada cadastro

2. Arquivos separados: implica em mais arquivos pra abrir (acesso a disco), mais programas de cadastro e relatórios.

3. Mesmo arquivo em alias diferente com filtro: acaba trafegando mais dados em rede

Só quem usa nestas condições é que poderia dizer o resultado de cada uma.
No momento trabalho do jeito 1, único arquivo, há alguns anos, e comecei com isso por causa do limite de arquivos abertos do Clipper.
No Harbour não há limite, mas não sei como ficaria o programa abrindo centenas de arquivos em rede.
Separar aumentaria de uns 80 DBFs pra 180 DBFs, e até o EXE vai aumentar, porque vai ter mais programas de cadastro pra arquivos diferentes. Hoje tem 1.5MB, e deve chegar a 2MB.

Alguém usa 180 DBFs num sistema em rede? funciona numa boa?

E abertura de arquivos? Abrir todos de uma vez para o sistema, ou do jeito que faço hoje - só abrindo os necessários?

Obs.
Em SQL não precisa dessa preocupação, porque sempre retorna um único recordset independente de quantas tabelas são consultadas. Então só resta saber se muitos arquivos seriam problema pra DBF.

[JoséQuintas]

Após ter separado umas 40 tabelas, o que gerou 80 arquivos a mais.....
o resultado foi uma demora em abrir arquivos.

Pra facilitar programação, e não esquecer de nenhum arquivo, comecei a abrir todos os arquivos do sistema em cada modulo.

Acho que a próxima etapa vai ser abrir tudo no início do sistema, e acrescentar um CommitAll em pontos estratégicos (como na passagem pelo menu)

Não sei se alguma falha de rede poderia danificar arquivos.

Um conhecido que trabalhava com Access comentei uma vez: todos trabalhavam normalmente o dia inteiro, e só no dia seguinte era acusado o problema de banco corrompido, devido a problemas de falhas de rede.

O negócio é acelerar a migração pra MySQL, assim tudo vira uma única conexão aberta, ao invés de vários arquivos abertos.

[Pablo César]

Um conhecido que trabalhava com Access comentei uma vez: todos trabalhavam normalmente o dia inteiro, e só no dia seguinte era acusado o problema de banco corrompido, devido a problemas de falhas de rede.

Mas Access ? Eu nem considero como banco de dados, é a pior coisa que a Microsoft inventou...

[JoséQuintas]

O Access sempre foi bom.
Um amigo programador VB6 usou por muito tempo, mesmo em rede, e sem no-break, era raro ter algum problema.
Até esquisito ser tão eficiente, com tudo amontoado num único arquivo físico.
Ainda é muito usado em sites, por estar disponível no windows.
Mas não compensa fazer algo novo com ele.