Tecnicamente, isso não é um problema que eu precise resolver. Estou desenvolvendo um projeto em que um aplicativo se conecta diretamente a um banco de dados do MS Access. O cliente sugeriu migrar o banco de dados para sua instância do SQL Server. O aplicativo, em seguida, usaria uma seqüência de conexão diferente para se conectar diretamente ao banco de dados do SQL Server em vez do MS-Access. Um teste simples comprovou que isso funcionaria, com dois usuários conectados ao mesmo banco de dados.
Não sei qual versão do SQL Server o cliente está realmente usando, mas presumo que eles saibam o que estão fazendo. No momento, estou adicionando algumas alterações de código adicionais e posso testar o aplicativo no SQL Server Express 2005 com até cinco usuários. Mas o cliente terá mais de 500 usuários que usarão o mesmo aplicativo ao mesmo tempo, portanto, haverá 500 conexões diretas com o banco de dados.
Não consigo convencer o cliente a pagar mais por um melhor modelo cliente / servidor deste projeto. Isso também exigiria algum tempo adicional de desenvolvimento. E não estou familiarizado com problemas que possam surgir com esses muitos usuários em um único banco de dados do SQL Server. Então eu sinto como se eu fosse o capitão do Titanic e eu acabei de ver um iceberg ...
Então, isso vai afundar? Quais são os riscos desta configuração que este cliente está negligenciando? Ou não há risco que vale a pena mencionar? (O cliente tem experiência com o SQL Server, então é principalmente eu quem está tendo dúvidas.)
O SQL Server 2005 funcionará bem, contanto que o usuário esteja usando uma versão licenciada para pelo menos 500 usuários. Você provavelmente iria querer suporte para mais de 500 por causa de conexões descartadas e coisas do tipo, mas eu recomendaria o SQL Server através do MS Access em qualquer dia.
Eu só queria acrescentar que o servidor SQL foi feito para ter milhares de conexões simultâneas, então eu não me preocuparia se fosse você.
Joshua está certo de que o SQL Server lidará com um grande número de conexões sem nenhum problema. Uma questão mais importante é se o esquema do banco de dados e o código do aplicativo serão capazes de lidar com isso.
Mais usuários tentando acessar e modificar os mesmos dados ao mesmo tempo provavelmente levarão a muito mais bloqueio de solicitações de todos os bloqueios de tabela / linha no banco de dados. O desempenho do aplicativo pode diminuir para um rastreamento com esse tipo de uso. Sem ver seu esquema de banco de dados, é difícil dizer. Embora suponha que você tenha feito uma conversão simples do Access para o MS-SQL, é provável que você não esteja aproveitando as vantagens de um RDBMS real, como restrições, chaves estrangeiras e indexação.
Outra coisa que você deve observar são os problemas que surgem devido aos vários usuários simultâneos. Projetar um aplicativo para um único usuário permite que você tome atalhos com itens como transações de banco de dados que precisam ser atômicas. Você se depara com o mesmo tipo de problemas na programação multi-threaded. Se você tem uma série de manipulações de banco de dados que precisam ocorrer juntas, o que acontece quando outro usuário inicia o mesmo processo enquanto o primeiro ainda não está pronto? O processamento do segundo afetará o primeiro? Se assim for, você precisará contabilizar isso.
Em última análise, o tempo dirá. Mas você pode ter mais trabalho do que esperava.
como um usuário SQL (e Access) muito experiente, eu concordo. o antigo MSDE2000 tinha um limite de conexão, mas o SQL Express mais recente não é governado de forma alguma. A versão Express será capaz de lidar com o número de conexões, mas a edição Express é limitada a apenas uma CPU, o que restringe um pouco as coisas.
Se você acabar precisando de mais energia, você terá que obter uma edição multi-CPU do SQL, que você tem que pagar.
Tags sql-server