Banco de dados

slack-user
(usa Slackware)

Enviado em 21/08/2017 - 22:31h

Boa noite Pessoal tudo bem com vocês?
Estou inciando um projeto com servidor linux (Slackware), sou iniciante, e estou com uma dúvida ao qual segue:
Meu projeto é em uma instituição sem fins lucrativos, que não tem uma infraestrutura adequada para armazenamento de dados Atualmente há documentos importantes distribuídos em várias máquinas, minha ideia é centralizar isso tudo em uma unica estação(servidor com linux) , pois bem, existe uma máquina lá que tem uma banco de dados access rodando em windows. minha dúvida é seguinte: Eu poderia colocar essas planilhas access em uma partição linux(seja ela qual for), e o usuário consegue executar esta aplicação através de um compartilhamento via rede na sua máquina local?.
obrigado pela disponibilidade pessoal.

madrugada
(usa Gentoo)

Enviado em 22/08/2017 - 07:11h

Em tese, você vai criar um compartilhamento samba que irá conter o arquivo.
Quando o Windows acessar este compartilhamento para abrir o documento do access, o documento será carregado para a memória ram da máquina local(Windows), e ali será feita todas as manipulações do arquivo. Quando o usuário clicar em "salvar", o arquivo da rede será sobrescrito com o arquivo que está na memória do Windows.
Então, é para funcionar.

Mas se a proposta é justamente arrumar a bagunça em que a casa se encontra, uma boa idéia é migrar estes dados para um SGBD de verdade. O Slack já vem com o MariaDB(fork do MySQL), que o usuário pode acessar pelo Windows com o Workbench ou SquirrelSQL. Se preferir, também pode facilmente instalar o PostgreSQL.
Um bom argumento para o usuário, é que isso vai aumentar a performance da máquina local, pois todo o processamento dos dados será efetuado no servidor.
Pense nisto!

Boa sorte!

hrcerq
(usa Outra)

Enviado em 22/08/2017 - 20:36h

Olá.

Concordo com o madrugada, já que vai organizar o ambiente, é melhor adotar uma solução mais robusta. Só que existem algumas considerações a fazer sobre isso:

Se você só criar o compartilhamento Samba e colocar os documentos do Access lá, o servidor só vai ter a "preocupação" de servir esses documentos. O processamento dos arquivos nesse caso seria distribuído entre as estações de trabalho, aliviando a carga de trabalho do servidor central.

Um SGBD central, como um MariaDB, MySQL ou PostgreSQL precisaria de um dimensionamento mais cuidadoso, porque ele vai ter que processar as requisições de todos os usuários (dependendo de quantos forem isso pode ter um impacto razoável). Deve-se considerar quantos acessos simultâneos ele vai receber, e a volumetria dos dados que ele vai processar.

Mesmo assim, a solução do SGBD continua sendo a ideal. Com ela, você vai poder ter controle de transações (ACID) que não teria com arquivos Access:

A - Atomicidade, a garantia de que cada transação acontecerá sempre por inteiro. Qualquer transação que não possa ser terminada, será completamente revertida para seu estado original.
C - Consistência, a garantia de que os dados estejam íntegros, e não sejam corrompidos durante as transações.
I - Isolamento, a garantia de que transações múltiplas e simultâneas não interfiram umas nas outras.
D - Durabilidade, a garantia de que a informação vai ser persistida enquanto for necessária.

Sem essas garantias, a informação acaba virando uma teia de documentos com informações repetidas e possivelmente inconsistentes. Isso gera custos maiores porque acaba-se gastando mais armazenamento e mais tempo na busca de informações, que podem ser equivocadas.

Mas o principal problema para implantar essa solução talvez seja a resistência dos usuários em migrar para uma solução diferente. Se eles já estão habituados a manipular os dados no Access, pode ser difícil convencê-los a usar o MySQL Workbench ou pgAdmin ou outro front-end, dependendo do SGBD. Dependendo do tipo de usuário, essas ferramentas podem ser um pouco cruas demais para eles, e aí teria que ter uma interface mais intuitiva, uma aplicação específica.

---

Atenciosamente,
Hugo Cerqueira

Mauriciodez
(usa Debian)

Enviado em 22/08/2017 - 23:31h

vc quer executar a aplicação (ACCESS) no servidor ou quer abrir o ACCESS no windows e abrir um .mdb que está no servidor LINUX ??? se quiser só abrir o .mdb do servidor pode abrir sem problema nenhum .


------------------------------------------| Linux User #621728 |-----------------------------------------

" Nem sempre é amigo aquele que te tira do buraco !!! ( Saddam Hussein )"

------------------------------------------| Linux User #621728 |-----------------------------------------

slack-user
(usa Slackware)

Enviado em 23/08/2017 - 10:56h

OI Madrugada, tudo bem?
Primeiramente gostaria de agradecer por disponibilizar um pouco do seu tempo para me ajudar.
Conseguiste esclarecer minha dúvida, e acho em um primeiro momento vou apenas colocar o banco access para o servidor, e com o tempo
posso fazer alguma coisa mais elaborada. A idéia a agora é deixar esses dados mais seguros.
Muito obrigado por sua atenção! abraço

slack-user
(usa Slackware)

Enviado em 23/08/2017 - 11:00h

Ola, hrcerq, Tudo bem contigo?
Gostaria de agradecer por tua contribuição, me ajudou muito também !
Vocês conseguiram sanar minha dúvida. Então num primeiro momento vou apenas colocar o banco access no servidor e as máquinas clientes executam ela através da rede.
Claro que futuramente, faço algo mais elaborado.
Muito obrigado por disponibilizar um pouco do seu tempo para me ajudar.
UM abraço.

slack-user
(usa Slackware)

Enviado em 23/08/2017 - 11:01h

Ola Mauriciodez, tudo bem?
A ideia neste primeiro momento é apenas executar o banco que esta sendo armazenado no servidor nas máquinas locais através da rede.
O pessoal (hrcerq e Madrugada ) também me ajudou e conclui que não teria problema em apenas salvar os dados no servidor.
Também agradeço por tua contribuição. Um abraço.

hrcerq
(usa Outra)

Enviado em 23/08/2017 - 12:14h

De toda forma, acredito que seria interessante colocar em seu projeto, caso não implemente agora, uma seção falando de melhorias futuras, explicando qual seria o cenário ideal e por quê, e explicar também do porquê disso ser inviável hoje e o que será necessário para implantar essas melhorias.

Isso pode fazer a diferença para essa instituição no futuro, quando talvez um outro projeto for feito por lá.

---

Atenciosamente,
Hugo Cerqueira