データベースのセキュリティ対策の一つとして、格納データを暗号化するという方法があります。
Oracle10gで暗号化の処理を実装する場合、以下のような方法があります。

各機能の利用方法については、いろいろなサイトに載っていますのでそちらを見ていただくとして、
ここではOracle10gから使用可能であるDBMS_CRYPTOパッケージとTDEの機能について、
私なりに使ってみた感想を書きます。

■DBMS_CRYPTOパッケージ
DBMS_CRYPTOパッケージは、SQLの中で指定する関数となります。
暗号化したい列に対して、アプリケーション側で明示的に暗号化ロジックを組み込んでいくことになります。
この方法で実装した場合、CPU負荷が高くなる場合があり、パフォーマンスへの影響もそれなりに考えられます。
暗号化したときの暗号鍵も、知られないように管理しておく必要があります。

では、暗号化した列のテーブルを参照したときはどのような挙動になるかといいますと、
DBMS_CRYPTOでの暗号化に関しては通常のテーブルと同じようにSELECTでデータを参照することができます。
とはいえ、暗号化した文字列でテーブルに格納されているため、SELECTでテーブルを参照しても
すぐには生のパスワードを知られることがないという利点があります。

■TDE(Transparent Data Encryption)
TDEは、データベースのほうで設定を行います。
設定を行っておけば自動的に暗号化・複合化を行ってくれるため、
アプリケーション側ではとくに意識することなく実装することができます。
CPU負荷もそれほど見られないため、パフォーマンスへの影響は少ないといえます。
また、暗号鍵はOracle Walletという別のソフトウェアで一括管理されます。

では、TDEを利用した場合のテーブル参照についてどのようになるかといいますと、
暗号鍵がクローズされている場合、暗号化した列はSELECT文で参照できずにエラーが返ってきます。
暗号化した列を含むSELECT文を発行しても同様にエラーが返ってきます。
つまり、"SELECT * FROM ～" というような書き方はできなくなります。
暗号鍵をオープンすることで、SELECTでエラーにならずにデータを参照することができます。
しかし、ここで注意しなければならないのが、暗号鍵をオープンしてテーブルを参照することで
生のパスワードが見えてしまうことです。
したがって、先の説明ではアプリケーション側では意識しなくてよいと書きましたが、
その代りに暗号鍵のオープン／クローズは意識する必要がでてくるのではないかと思います。

上記の内容をそれぞれまとめると、以下のようになります。

Oracleが提供している資料などを見るとDBMS_CRYPTOパッケージよりもTDEのほうが良さそうな気はしますが、
TDEを使っても結局のところアプリケーション側で意識する必要は出てくるのではないかと思います。
そう考えるとTDEのほうは、SELECTで何も表示されないのならまだしも、
エラーが返ってくるというのが非常にマイナス点だと感じました。
（パフォーマンスがどの程度影響出てくるのか気になるところではありますが・・）
使う場面によりけりですが、TDEよりもDBMS_CRYPTOパッケージのほうが使い勝手は良いという印象です。

私が使用した時の感想なので主観的な意見が多々あるかと思いますが、
ここは違うぞ、という部分がありましたら指摘いただければと思います。