Banco de dados hospedado em nuvem
Pessoal estou querendo hospedar meu banco de dados em nuvem,mas estou com algumas dúvidas,tenho uma aplicação em desk que será instalada em vários desktops,onde todos eles irá buscar e enviar informações desse banco, minha dúvida é, como praticamente a todo momento irá realizar consultas para ver se determinado registro está em uma tabela e se estiver ele irá fazer updates e inserts,oque eu queria saber é, se como ele está em nuvem, todo momento os desktop terá que ter conexão com a internet,se cair a conexão com a internet já travaria a aplicação,no caso consulta updates e inserts, ou para evitar isso teria que fazer um select da tabela e salvar em uma tabela temporária por exemplo e de vez buscar as informações a todo momento do próprio banco em nuvem,buscaria dessa tabela temporária,e para fazer inserts usaria outra tabela temporária e depois mandaria tudo de uma vez para o banco em nuvem ?
Alan
Curtidas 0
Melhor post
Claudio Andrade
08/11/2023
Pessoal estou querendo hospedar meu banco de dados em nuvem,mas estou com algumas dúvidas,tenho uma aplicação em desk que será instalada em vários desktops,onde todos eles irá buscar e enviar informações desse banco, minha dúvida é, como praticamente a todo momento irá realizar consultas para ver se determinado registro está em uma tabela e se estiver ele irá fazer updates e inserts,oque eu queria saber é, se como ele está em nuvem, todo momento os desktop terá que ter conexão com a internet,se cair a conexão com a internet já travaria a aplicação,no caso consulta updates e inserts, ou para evitar isso teria que fazer um select da tabela e salvar em uma tabela temporária por exemplo e de vez buscar as informações a todo momento do próprio banco em nuvem,buscaria dessa tabela temporária,e para fazer inserts usaria outra tabela temporária e depois mandaria tudo de uma vez para o banco em nuvem ?
Essa não seria nem de longe o cenário ideal para uma aplicação desktop, visto que você provavelmente vai precisar manter uma transação aberto no momento que faz as requisições, deixando o sistema lento e exposto, além do alto consumo de dados o que pode aumentar o custo.
Para a finalidade que você esta querendo, o recomendado seria criar uma api e seu sistema consumir essa api.
Não programo em Delphi ja faz algum tempo, mas sei que hoje existe alguns frameworks que possibilitam criar uma api com pouco esforço.
Boa sorte!
GOSTEI 1
Mais Respostas
Alan
08/11/2023
Pessoal estou querendo hospedar meu banco de dados em nuvem,mas estou com algumas dúvidas,tenho uma aplicação em desk que será instalada em vários desktops,onde todos eles irá buscar e enviar informações desse banco, minha dúvida é, como praticamente a todo momento irá realizar consultas para ver se determinado registro está em uma tabela e se estiver ele irá fazer updates e inserts,oque eu queria saber é, se como ele está em nuvem, todo momento os desktop terá que ter conexão com a internet,se cair a conexão com a internet já travaria a aplicação,no caso consulta updates e inserts, ou para evitar isso teria que fazer um select da tabela e salvar em uma tabela temporária por exemplo e de vez buscar as informações a todo momento do próprio banco em nuvem,buscaria dessa tabela temporária,e para fazer inserts usaria outra tabela temporária e depois mandaria tudo de uma vez para o banco em nuvem ?
Essa não seria nem de longe o cenário ideal para uma aplicação desktop, visto que você provavelmente vai precisar manter uma transação aberto no momento que faz as requisições, deixando o sistema lento e exposto, além do alto consumo de dados o que pode aumentar o custo.
Para a finalidade que você esta querendo, o recomendado seria criar uma api e seu sistema consumir essa api.
Não programo em Delphi ja faz algum tempo, mas sei que hoje existe alguns frameworks que possibilitam criar uma api com pouco esforço.
Boa sorte!
Obrigado Cláudio.Poderia me indicar algum hospedeiro pra hospedar meu banco de dados ,e me explicar mais ou menos como seria feito essa api?
GOSTEI 0
Arthur Heinrich
08/11/2023
Existem várias arquiteturas distintas para uma aplicação. Cada uma delas visa mitigar algum problema.
Seu sistema pretende acessar um banco remoto. Neste contexto, remoto pode ser na própria máquina ou a milhares de Km de distância. Você terá que utilizar uma conexão de rede para isso e ela pode falhar.
Para evitar que uma falha de conexão (não detectada pelo banco) preserve sua sessão com transações em aberto, que podem reter locks e provocar bloqueios, o ideal é que uma requisição ao banco represente uma transação completa.
Por exemplo, se uma transação envolve múltiplas tabelas, ela poderia ser executada via stored procedure. Assim, uma única chamada iniciaria e terminaria a transação, liberando os locks.
Também não é bom, abrir e fechar conexões a cada comando enviado. A autenticação de um usuário é bastante custosa, consome recursos importantes e isto limitaria a capacidade do banco e a velocidade da sua aplicação.
O ideal é utilizar um pool de conexões, reutilizadas, caso hajam tarefas sendo executadas em paralelo, ou que a aplicação mantenha a conexão aberta durante a execução da aplicação.
Ao executar um comando, em caso de falha, você pode reabrir a conexão e reenviar o comando.
Você pode simplificar essa tarefa encapsulando a execução em uma procedure sua, que faça a verificação e, se necessário, reabra a conexão. Se você não fizer isso, terá um sistema com múltiplos pontos de falha e terá que checar falhas de conexão em muitos locais, replicando código desnecessariamente.
A alternativa de menor esforço e nada elegante é, ao detectar um problema, peça desculpas ao usuário pela falha, feche o programa e o usuário que tente novamente.
Seu sistema pretende acessar um banco remoto. Neste contexto, remoto pode ser na própria máquina ou a milhares de Km de distância. Você terá que utilizar uma conexão de rede para isso e ela pode falhar.
Para evitar que uma falha de conexão (não detectada pelo banco) preserve sua sessão com transações em aberto, que podem reter locks e provocar bloqueios, o ideal é que uma requisição ao banco represente uma transação completa.
Por exemplo, se uma transação envolve múltiplas tabelas, ela poderia ser executada via stored procedure. Assim, uma única chamada iniciaria e terminaria a transação, liberando os locks.
Também não é bom, abrir e fechar conexões a cada comando enviado. A autenticação de um usuário é bastante custosa, consome recursos importantes e isto limitaria a capacidade do banco e a velocidade da sua aplicação.
O ideal é utilizar um pool de conexões, reutilizadas, caso hajam tarefas sendo executadas em paralelo, ou que a aplicação mantenha a conexão aberta durante a execução da aplicação.
Ao executar um comando, em caso de falha, você pode reabrir a conexão e reenviar o comando.
Você pode simplificar essa tarefa encapsulando a execução em uma procedure sua, que faça a verificação e, se necessário, reabra a conexão. Se você não fizer isso, terá um sistema com múltiplos pontos de falha e terá que checar falhas de conexão em muitos locais, replicando código desnecessariamente.
A alternativa de menor esforço e nada elegante é, ao detectar um problema, peça desculpas ao usuário pela falha, feche o programa e o usuário que tente novamente.
GOSTEI 0