This has a couple of implications:

• The database server needs to live on a separate box from the web server. If it doesn't, and the web server is hacked, all bets are off. Having the password encrypted in the database won't help you if the encryption algorithm and keys are exposed.
• The database server must not accept connections from the web server box. If it does, and someone hacks the web server box, all bets are off.
• The database box should not accept connections from the internet in general (with the possible exception of an SSH). Otherwise the database server is hackable, and all bets are off.
• The web server communicates with the database server through an intermediary in a protocol that does not include raw SQL. Otherwise, the hacker can pass SQL through the intermediary, and all bets are off.

The intermediary is an "application server", and is either housed on its own box (a "three tier" configuration), or it's colocated with the database. (Big players go three tier, with firewalls between each tier).

Writing a simple application server is actually pretty easy. Code for accepting socket connections is widely available, so that part shouldn't be too difficult. (Lincoln Stein's Network Programming with Perl is a great reference.) Accessing the database is also pretty easy.

The trickier part is in designing the protocol. A simple way to start is to look at your existing queries in terms of inputs and outputs, and to wrap each query up inside of a "command" that the web server will then send to the application server. If you use XML to express the inputs and outputs, you're on the road to XML-RPC or SOAP.

If you get this far, and assuming that your application protocol doesn't include something like getAllCreditCardNumbers(), then the credit card data as a whole is probably safe, though encrypting it in the database might help you sleep at night.