Relacionamento vs Desempenho e Exaustidão de transação de dados

Amigos bom dia!


Venho abrir um tópico com senso critico de vcs que mexem com access a um tempo...

Minha duvida é:

tenho um volume de dados cerca de 15 mil dados movimentados em uma rede. Cerda de 25 pessoas usariam o access.

O que seria melhor eu fazer ?

Separar o back-end dos dados em outro arquivo access e fazer conexão entre eles tipo Back-end e Front-end?

ou tudo junto?

A tendencia e aumentar o volume de dados... cerda de 130 à 250 inseridos novos por mês.

Pra consulta esse volume pode demorar um pouco a retornar ?

qual seria o tempo pra manutenção de dados desse banco ? uma estimativa mais o menos?

vcs acham que nao dariam crash no BD em um ano?

Complementando meu topico com topico do JP, segundo ele. Tem um bd em access com volume de dados mais de 1 milhao de dados e com 25 pessoas utilizando simutaniamente.


Minha base seria em torno de um volume igual a 23.837 dados totais com inserções por ano de 1560 - 4200


abraços

Olá Nathan, com dois utilizadores, já se justifica separar front end de back end.
Com 25 não existe dúvidas.
Aproveito para lembrar o front end não deve ficar na rede para todos usarem, mas sim, copiado para a unidade c:\suaApp de cada posto e deve ser a partir desta que cada posto deve abrir o seu projeto.
Efetue a divisão e depois venha dar o retorno do resultado obtido.
Ficamos aguardar.

Abraço

Texeira

a duvida é...

Com 25 usuarios ! mesmo tendo separado back e front sera que crasharia o back-end?


mais alguem ?
conto com ajuda de experiencias...


abraços

Olá, cracha mais depressa se não dividir.
Aguardamos mais testemunhos/opinioes dos colegas.
Abraço

Olá a todos;

Ao dividir um banco de dados, você sabe que todos os usuários estão acessando aos dados mais atuais porque todos estão acessando aos mesmos dados.
Não só acessam como podem atualizá-los ao mesmo tempo.
Isso significa que uma alteração feita por um usuário está quase imediatamente disponível para todos os outros.

Ter um back-end, tem duas grandes vantagens:

1º Todos os dados em um único arquivo de banco de dados.
2º Minimiza a corrupção do banco, muito usual nas versões anteriores ao 2003.

Um conselho que lhe dou pela experiência é:

Desenvolva as suas tabelas de forma definitiva, para que quando colocar o back-end na rede, não existir alterações de acrescentar ou deletar campos.

Se o back-end inchar muito, que não vai ser o caso pelos numeros que você nos passou, aconselho a fazer backup desse back-end e no que fica na rede
deletar dados antigos, fazendo depois o compactar/reparar.

não sou da área, mas além utilizar back e front, percebo um desempenho melhor com forms desacoplados + DAO.

abraços,

@JP

o que vc quis dizer com isso: Desenvolva as suas tabelas de forma definitiva, para que quando colocar o back-end na rede, não existir alterações de acrescentar ou deletar campos.?
me de exemplos pf
o que seria Desenvolva as suas tabelas de forma definitiva?

abraços

@cleverson_manaus

obrigado a informação, não gosto de trabalhar com forms acoplados, ou seja, sera de grande utilidade então

abraços

Amigão;

O back-end apenas vai ter as tabelas quando você dividir o banco.

Como essas tabelas vão estar ligadas a todos os front-end`s, qualquer alteração que você vier a fazer na estrutura das tabelas, vai ter de revinvular de novo em todos os seus front-end`s, caso contrario, vai dar erros e pode até corromper o back-end.

@jp amigao!

mto obg pelas dicas, pretendo somente vincular no final de toda a estrutura do projeto estiver pronto e validado entendeu. Como vou trabalhar com prazo pensei em jogar pro final por ser de exterma responsabilidade de corrupção de dados e bd.

Mais alguém ? toda experiencia é bem vinda!


abraços

Olá pessoal do fórum,

[Acredito que esse seja um tópico adequado para postar meu problrma]

Tenho um BD (em Access 2016) em que até 12 usuários utilizam ao mesmo tempo. Ele fica apenas numa pasta da rede em que todos abrem o mesmo arquivo.
(Não sabia que era possível dividir o banco de dados )
Ele estava funcionando bem, porém após um mês de uso, ele corrompeu pois o arquivo ficou muito pesado (2GB).
Para solucionar esse problema, toda vez que ele está próximo de corromper novamente, crio uma nova cópia e subo as bases novamente. Isso faz com que seu tamanho reduza bastante, mas não é o ideal.
No entanto, recentemente (após 4 meses de uso aproximadamente), os usuários estão tendo problemas com os dados, que não estão atualizando simultaneamente entre eles, o que gera troca de informações erradas.
Minhas dúvidas são: se eu criar o back-end/front-end, esse problema será resolvido? Pode existir outros motivos para que isso tenha começado a ocorrer? Alguém teria uma sugestão do que posso fazer?

Obrigada desde já!

Olá Isabella Farinazzo,

É exatamente isso, dividir o banco de dados em BackEnd e FrontEnd.

o BackEnd fica na rede (apenas com tabelas de dados)
o FrontEnd fica com os restantes objectos (forms,reports,modulos, tc), seja em accdb ou accde (compilado), este por sua vez fica vinculado (ligado) às tabelas do BackEnd.

Por último, sou da opinião de copiar o FrontEnd para a unidade de disco local (c:\SuaPasta) em cada posto (em cada um dos 12 utilizadores).

Abraço

Olá Alvaro,

Obrigada pela resposta.
Eu tentei fazer isso, mas depois de algumas horas o sistema já se tornou lento e travou. E ainda estava com 6 usuários, apenas.
Fiz como você falou, e coloquei os front-ends nos discos locais, e o back-end numa pasta da rede.

Não sei mais que tipo de solução posso fazer

Obrigada

Olá Isabella Farinazzo,

Optimo, já é um avanço.
Não informei na mensagem anteriror, mas os utilizadores devem arrancar com o FrontEnd do disco local.
Ao vincular (ligar) as tabelas deve-se usar o caminho UNC, exemplos:

\\NomeComputadorServidor\NomePasta\BackEnd.accdb
\\192.168.xxx.xxx\NomePasta\BackEnd.accdb

Também deve verificar as permissões de escrita e leitura da pasta e ficheiro partilhado (da rede)
O BackEnd, como já referi, só deve ficar com as tabelas.

Se o problema se mantiver, aí deve-se verificar como tem a modelagem dos dados e programação.
De momento não me está ocorrer mais nada.

Aconselho a ter BACKUPS de momentos diferentes pode adicionar a data e hora, exemplo:
BackEnd_20170825_1000

Abraço

Acredito que um dos critérios importantes, realmente, é a modelagem dos dados.

Outro é a configuração de bloqueio em nível de página ou registro, esses dois tipos de bloqueio influenciam tanto no desempenho do banco como na integridade dos dados .


Dê uma olhada nesse link:


support.office.com/pt-br/article/Agilize-a-execu%C3%A7%C3%A3o-do-Access-f6827763-bb5c-4f48-8457-7a14addab6be#bm2
Copiar link e colar no nabegador

Abraços,