For a software application, does every workstation need database drivers? really a just a newb question. In the case of something like an enterprise system for a company, where end-users are executing continuous reads and writes to a database, it does not appear that in most cases each workstation needs the database being used's drivers. Credentials are being passed through the software, to the databases IP and port, and I am supposing that when a new user is added to the software, it is adding them to the database and their read / write privileges are assigned at that point. The user provides their login information to the software which serves as their credentials to make read / writes to the database.

However, if I want to access the database from third-party software, Excel or what not, I then do need the drivers for the database. I guess I am not sure why this is and was wondering if someone could explain it to me.

An example, a company I used to work for used IBM DB2. We had an enterprise system around it with DB2 as the database. Using the software surrounding it, I don't recall ever needing the drivers for it. When we started writing custom reports for it in Excel, then I needed the ODBC drivers as did any other workstation that needed the Excel -> DB2 connection.
It all depends on the application and how it is designed.

Two main cases:


Client application connects to an application server, application server connects to the database.

In this case, no need for database drivers on the client side. The client application never talks directly to the database but calls the server-side software only. The client application in this case can be a web browser or a custom application (large or small) - doesn't matter. The application server software hides the details, and the end-user workstation doesn't even know what type of database (if any!) is used in the backend.

This is how most of the web works.

Here, end-users don't necessarily need credentials on the database. Some applications require it (they essentially delegate authentication to the database), some on the other hand deal with the authentication themselves. In that case, the server-side application software will have credentials on the database but the end-users will not. The server-side application will usually use the database to store identifiers and privileges in its own format, and allow/deny actions based on that.  

The end-users won't need network access to the database server(s) in this scenario, only to the application servers.
Client application connects directly to the database

Usually in this case, the client-side application is fairly large (for "Enterprise" software). All the application processing is done in the client-side software and/or stored procedures in the database, the client interacts directly with the database.

Here you need drivers on the client side. (But that may not require a separate driver installation. E.g. a Java application could come bundled JDBC drivers and use those directly.)

End-users need to have credentials in the database, with appropriate privileges (I'm completely ignoring some horrors with shared accounts). They also need network access to the appropriate port(s) on the database server(s), either directly, via proxies, VPNs or whatever.


(And there are hybrids of these two approaches, with some work done via an application server, some directly on the database. I haven't seen many of those though.)

The first case is more common these days in my experience, with the browser having become the most commonly-used client-side software.