The best way to remedy database traffic overload is to fine-tune the way your client application queries the database. There's a huge difference between configuring your client to query the database with "give me all the data about all our customers and I'll sort through them" and "give me information on customers such as X, but only their names, addresses and phone numbers."
If the application's SQL implementation limits the result set, the query will carry less data. The more users, however, the greater the impact queries have on the applications and the network. One or two users can get away with a query that selects, for instance, all 25,000 100-byte long records. But when 300 users attempt that, you have a problem. Then you need to optimize your queries or your database and revisit your network bandwidth and design.
If you have a single active connection to the database, meanwhile, only a minimal amount of traffic can traverse it--bad news for database performance but good news for the network. If you have multiple active connections that sit idle for a long time, however, you may be placing an unnecessary load on your network because most database technologies use messages to keep a connection open. Depending on the type of idle connection, you may want to reduce your number of active connections.
A Measure of Success
To gauge your database traffic's effect on the network, you must measure it with a network monitor. We used the open-source packet sniffer Ethereal, but any packet sniffer will do. After pointing Ethereal at the database server, we ran our application code and walked through the results to see what was happening.