About efficiency: symmetric encryption (like AES) of comparable security level will always be faster than asymmetric one (like RSA).
Because of this (and since RSA needs some random padding to be secure, meaning the ciphertext is a bit larger than the plaintext), the usual way to use RSA (if you have to encrypt more than about the key size) is to generate a random key for a symmetric algorithm, encrypt that key with RSA, encrypt the plaintext with this random key, and store the encrypted key together with the plaintext.
So, your selection is actually between:
- RSA (with public + private key) together with AES (or some other algorithm, but let's stay simple)
- only AES (with a secret key)
The actual cryptography here is not a point where an attacker will get any advantage - both AES and RSA (with the given key size) are secure enough to resist brute-force attacks.
If you are using only symmetric encryption, of course the encrypting server needs this key, and if compromised, this key can be used to decrypt the data in the database. There is not really a way around this.
If you are using asymmetric encryption, your encrypting server could have only the public key – but this is only a viable option if this webapp server never needs to decrypt the data again, i.e. for write-only data. Do you really have such data? (It can be modified after submitting, but only by overwriting it, not by first reading it, changing and writing back.)
Also, since this is using a public key for encrypting, there is nothing hindering an attacker with database access from changing the data to something else. If an attacker somehow gets access to the database (he shouldn't, of course), it is not that complicated to derive the public key from the encrypted data. Having that, the attacker can simply insert new records into the database, or overwrite old ones, and your decrypting process (with the private key) has no chance to see the difference. To avoid this, have the writing process also sign the data (with the private key of a different key pair), where the reading process can verify these signatures.
You can have a second server to decrypt it for the first one on demand, but this will not be much safer than having the first one do it itself (only that you can simply cut it off when you remark the attacker's presence).
So, to completely estimate your security, it is necessary to first have an attack model (i.e. against which attacks do you want to be sure), then you can judge which variant protects better.
I want to be sure the Internet facing server doesn't get attacked.
The encryption of the database by itself does not open (or close) any attack route on the web server, either way. They are only different if some attacker finds another security hole in your web application, and gets access to the web server.
