realmente uma questão newb. No caso de algo como um sistema corporativo para uma empresa, onde os usuários finais estão executando leituras e gravações contínuas em um banco de dados, não parece que na maioria dos casos cada estação de trabalho precise dos drivers do banco de dados sendo usado. As credenciais estão sendo passadas pelo software, para o IP e a porta do banco de dados, e suponho que quando um novo usuário é adicionado ao software, ele o adiciona ao banco de dados e seus privilégios de leitura / gravação são atribuídos nesse ponto. O usuário fornece suas informações de login ao software que serve como suas credenciais para fazer leituras/gravações no banco de dados.
No entanto, se eu quiser acessar o banco de dados de um software de terceiros, Excel ou outro, preciso dos drivers para o banco de dados. Acho que não tenho certeza do porquê disso e queria saber se alguém poderia me explicar.
Um exemplo, uma empresa para a qual trabalhei, usava o IBM DB2. Tínhamos um sistema corporativo com o DB2 como banco de dados. Usando o software que o envolve, não me lembro de precisar dos drivers para ele. Quando começamos a escrever relatórios personalizados para ele no Excel, eu precisava dos drivers ODBC, assim como qualquer outra estação de trabalho que precisava da conexão Excel -> DB2.
Tudo depende da aplicação e de como ela foi projetada.
Dois casos principais:
O aplicativo cliente se conecta a um servidor de aplicativos, o servidor de aplicativos se conecta ao banco de dados.
Nesse caso, não há necessidade de drivers de banco de dados no lado do cliente. O aplicativo cliente nunca se comunica diretamente com o banco de dados, mas apenas chama o software do lado do servidor. O aplicativo cliente, neste caso, pode ser um navegador da Web ou um aplicativo personalizado (grande ou pequeno) - não importa. O software do servidor de aplicativos oculta os detalhes e a estação de trabalho do usuário final nem sabe que tipo de banco de dados (se houver!) é usado no back-end.
É assim que a maior parte da web funciona.
Aqui, os usuários finais não precisam necessariamente de credenciais no banco de dados. Alguns aplicativos exigem isso (essencialmente delegam a autenticação ao banco de dados), alguns, por outro lado, lidam com a própria autenticação. Nesse caso, o software aplicativo do lado do servidor terá credenciais no banco de dados, mas os usuários finais não. O aplicativo do lado do servidor geralmente usará o banco de dados para armazenar identificadores e privilégios em seu próprio formato e permitir/negar ações com base nisso.
Os usuários finais não precisarão de acesso à rede para o(s) servidor(es) de banco de dados neste cenário, apenas para os servidores de aplicativos.
O aplicativo cliente se conecta diretamente ao banco de dados
Normalmente, neste caso, o aplicativo do lado do cliente é bastante grande (para software "Enterprise"). Todo o processamento do aplicativo é feito no software do lado do cliente e/ou procedimentos armazenados no banco de dados, o cliente interage diretamente com o banco de dados.
Aqui você precisa de drivers no lado do cliente. (Mas isso pode não exigir uma instalação de driver separada. Por exemplo, um aplicativo Java pode vir com drivers JDBC agrupados e usá-los diretamente.)
Os usuários finais precisam ter credenciais no banco de dados, com privilégios apropriados (estou ignorando completamente alguns horrores com contas compartilhadas). Eles também precisam de acesso à rede para a(s) porta(s) apropriada(s) no(s) servidor(es) de banco de dados, diretamente, por meio de proxies, VPNs ou qualquer outro meio.
(E existem híbridos dessas duas abordagens, com algum trabalho feito por meio de um servidor de aplicativos, alguns diretamente no banco de dados. No entanto, não vi muitos deles.)
O primeiro caso é mais comum atualmente em minha experiência, com o navegador se tornando o software do lado do cliente mais usado.