Ah yes, the base 36 conversion to "bad" words. Probably most people have run across this at least once in their lifetime.
It reminds me of something I did with a secure HR document system that could make the actual files look inconspicuous to a wouldbe thief (be it internal or external) who hacked into our system. We used the primary key and did a base 36 conversion for the file name and then changed all the extensions to .001 so that the thief wouldn't know what they had if they came across it. We built a COM object to do the conversions to the "proper file name" when moving the files to a web-based viewer. Besides the "bad" words, which really didn't matter to us because no one would see them, we ran across "reserved" words in Windows (like LPT, PRN, etc.) that rendered the files unusable -- as in, we couldn't open them, we couldn't delete them, and we couldn't move them to be viewed. A simple lead zero filling fixed this.
Probably the worst database mess I ever saw was one with no keys on anything. Typically the first thing I'll do when working with a new database is to simply draw a diagram using Enterprise Manager or some similar tool. This particular database had about 300 tables in it, and when the diagram finished, I didn't see anything on the screen. As I started zooming in, I noticed a "dotted line" spanning for miles -- every table had been lined up side by side because there were no foreign key relationships in the entire database. Their DBAs also never joined two tables together using inner joins; everything required a left join because there was no referential integrity. This database drove a major piece of software being used for income tax returns, and my short one month stay there left me shaking my head and pulling out my hair. Customer's data would appear on the screen and the drop-down lists that should've defaulted with the "current values" had nothing selected because the definition for PaymentID = 6 had no related value in the Payment table.