Should I Do This Or Should I Shoot Myself Instead?

I'm developing a new application and up until today to keep track of who added, removed or updated the records in the database tables I would do something like this:



Table: Membership

Id

FirstName

LastName

LastModifiedByMembershipId

LastModifiedDate

AddedByMembershipId

AddedDate

RemovedByMembershipId

RemovedDate



Table: Usergroups

Id

Name

LastModifiedByMembershipId

LastModifiedDate

AddedByMembershipId

AddedDate

RemovedByMembershipId

RemovedDate



Well this works fine but it has three major drawbacks:

You can't create a cascade action on all 3 (...)ByMembershipId. SQL Server returns a "loop" error;
When the record is modified more than once its only possible to keep track of the last change;
It's boring as hell to create those fields in every single table, as well as the correspondent indexes.

With these problems in mind I'm considering a new approach for this new application. In this approach I would have 3 tables. One containing the possible actions (e.g. insert, delete). Another containing the names of all the tables. Last, but not least, I would create a table to keep track of all the changes that occurred to every single record in the database, and these is where the problems start. It's going to be a busy site, lots of updates, inserts, deletes, which as a result will turn this table into a huge table in no time.



What do you guys (gurus) think about this approach? Like I wrote on the subject should I shoot myself instead, as this would be a performance handicap?



Best regards and thanks in advance