Database – Storing revisions of a document

To answer your question, you need to answer this:
Does the stack trace provide useful, additional diagnostic information that the exception itself doesn't have?

If yes, then sure, go ahead and store the stack trace information.

If no, then don't waste your time.

As to how to store the stack trace, there's all sorts of methods that you can consider. For example, it's fairly trivial to create a routine that converts the stack information into strings and then store those strings. Likewise, you could pull whatever additional arguments are on the stack and push those into the strings that you're creating. It all depends upon what information you need.

More broadly, you should log information that helps you diagnose and resolve issues. Whether you store that in a log file or a database is somewhat immaterial. The point is that you're trying to record the error information when the error occurs.

If you're worried that the error information won't persist with whatever mechanism you chose (aka your logfile got deleted) then you need to come up with a more robust persistence mechanism for the error information. But that problem is a separate issue from whether or not you should log XYZ information about an error.

No, they're not. The purpose of auditing is to determine who did what in the past. The current data is irrelevant for this purpose, but you will need to record which data changed - there's no point in saying "user Dave change the person table" without saying what he changed. This information doesn't have to be recorded so formally though.

You might like to store the table that was modified, and a text field containing the data changes to assist in filtering the audit records during an investigation, or just the data changes if you can filter on other factors or substring searches of the text.