I'm trying to understand why storing your logs in the production database is such a bad idea. Is it because of potential disk contention? Lock issues? Could you be more specific about why it is a stupid idea?
Probably just disk contention - locking is unlikely to be a problem since you're just adding rows.
The disk contention issue could be a problem because writes are hard to scale, but depending on the regularity of logging and the indexing used (I'm assuming it's done by timestamp here) it's probably not actually the biggest of deals - you should end up mostly doing append-only writes. In oracle, for example, all that'll happen is that for each log transaction some stuff will get altered in memory (i.e. a block of the table will get appended to, and an append will occur on the index) and the roll forward log will get written to on disk. Every so often the table and index blocks will get written to disk, but that will be much less than once per transaction in an appending case.
That said, overall I'd still recommend having the logging done on a separate system, or at least having profiling set up on your log table/user/whatever such that logging can't eat your production server if someone decides to excessively ramp up the log levels.
Why not just move the logging table into a different tablespace/file group and place this on a different disk? That would fix write performance problems.
This is absolutely a good thing to do, but it doesn't make you safe - the disks running the database's redo logs are the ones that get hammered in a logging scenario (since the writes to the table and indexes are largely appending, and don't have to be written to disk to commit a transaction). These logs are usually global to the DB instance, so you can't easily (to my knowledge) separate them out. This being the case, they can significantly affect the performance of the rest of your system if too much logging starts happening.
