Connection pooling is the best short-term solution. By making a few simple changes to your application server's configuration files or a slight modification to your source code, you can get a huge reduction in bandwidth usage. Much of the benefit of this approach depends on your users' access patterns. If many users hit the database repeatedly, the performance improvement will be noticeably large because you won't be rebuilding connections repeatedly. But if you have just a few users performing long-running queries, the improvement will be minimal.
A long-term solution is to review the queries your applications use against your database. Queries that return unnecessary columns or too many rows, and queries that return data and then use the result to go back to the database for more data, are problems.
If you still can't reduce network traffic using these methods, go Gigabit Ethernet on the connection from the switch to your database and application server. Gigabit networking technology costs have dropped, so increasing the pipe size is no big deal. This is a good solution if your application uses an application server or if you're having problems because of congestion between the database and the application server. If your application has a fat client to the database, you need to upgrade your backbone so the switches are gigabit-connected as well.
Watch out for Web services. If they aren't configured properly, they can hit your database too much. Writing a Web service that selects and returns a single value from a database row is a no-brainer, but it poses a health hazard to your database and your network. If your organization has 15 Web services modules that each return a single field from the same table, for instance, that places 15 expensive call-response sequences on your network, and your database executes the query 15 times.
Even when implemented correctly, Web services create more network traffic than a traditional query because of two factors: the SOAP (Simple Object Access Protocol) envelope and the translation of result sets to XML/text. When used incorrectly, the overhead can be large--about 250 bytes per call, plus the difference in size between your database's representation of the data and a text translation of that data.