My coworker Jakeypoo was kind enough to send in this tale ...

I'm sure we all have our stories of nightmarish projects inherited from clients, whether the secretary's cousin programmed a critical application in JavaScript or a community outreach program let a group home design their customer tracking application.  Imagine my surprise when we got one that had beautifully written, well-commented ASP pages.  I thought this would be easy.

My boss asked me to put together a diagram of the database so that I'd be able to refer to it for table and column names, keys, etc.  I fired up our diagramming software, and watched in horror as it processed the tables.

Cn.  CnAdr.  CnAdrPrf.  CnAdrPrfPh_1.  CnAdrSal.  CnAttr... (time passes)
CnRelEdu_1Attr.  CnRelEdu_1AttrCat_1.

"It's ok, Jakeypoo, you'll figure out what all of these are by looking at the data and key relationships," I reassured myself.

Cracking my knuckles, I leaned forward.  "You've seen worse than this.  You saw an old lady die at a restaurant once (for serious).  Let's DO this!"

No foreign key relationships?  Ok, that's fine.  You should expect this by now. Keep going.  No... no primary keys?  In any of the tables?

OK, Jakeypoo.  You're a smart guy.  Look through the actual data.  The "Cn" (central nervous?) table seems pretty important.  Let's see what we've got.

There's a pattern here, bend your brain and see if you can find it! 
CHALLENGE POINT:  Can you guess what values are in record 494?

Now of course ... he's being a bit generous. This database was developed for our client by the same programmer who refuses to use views and stored procedures. To be fair, this application is an exception to the rule; we generally produce top of the line, high-quality, easy-to-maintain software code.