Is this optimal? Maybe. What are your audit requirements? Here are some things to consider. Auditing should be separate from your production data. This is a typical requirement. Review the requirements again. And again. And again. Have the actual auditors review your plan. You may the tracking the correct data, but the METHOD you are using to track the data may not fit the audit requirements. For example, we had our audit plan rejected because the same DBA's had access to the source data and the audit data. These needed to be separate persons.

More optimal? From what perspective? Performance? Meeting or exceeding audit requirements? Architecture?

My first generic thought was that a single audit table will probably not scale well. Separate audit tables for each "table" you are auditing may make more sense. If you are going to do this with triggers (Ugh!) the contention for this table from multiple places may become a blocking and locking issue. It may work well for 10 users, but it will become an issue with 100. The audit table may be a good candidate for a heap. The activity on this table will likely be primarily inserts, so make inserts as fast as possible. Indexes will slow this down.

Would a separate trigger need to be created for each field we wish to log?

Huh? Sounds like a trip to Books Online land is in order. Look up UPDATED

Sample syntax:

If UPDATED(field) Begin

Do something

End

You need three triggers (Ugh!); insert, update and delete.

Lastly, do some significant performance testing. Capture your baselines when you do 100, 10000, and 1000000 inserts/updates/deletes on the tables to be audited. Then add your triggers and do the same test.