In my opinion; Using tables to store DDL changes is efficient way instead relying on trace files only. The reason I see are;

- Trace file(s) may get deleted over a period of time.
- Trace files will not provide you actual T-SQL
- With Table; its very easy to search from years old data to find out multiple version of an SP or changes in it. However, trace files are recreated with every SQL restart makes it hard to club all files.
- With Trace Tables; You can add multiple alerts or create daily/weekly or monthly report for DB schema changes easily for further analysis.

let me know what you think…

Schema changes are recorded in the default trace and there is a standard report available from SSMS to determine any DDL changes per database.

It is also simple to extract the details from the default trace

declare @logfilename sysname

select @logfilename = path from sys.traces where id = 1

SELECT Eventclass,
case
when EventClass = 164 then ‘Alter’
when EventClass = 46 then ‘Create’
else ‘Drop’
end as [DDL Action], LoginName,SPID,StartTime,ObjectID,ObjectName,DatabaseName
FROM fn_trace_gettable(@logfilename, default)
where eventclass in (164,46,47)
and DatabaseID > 4
and ObjectName is not null

There can also be a problem with a subscriber in a replication scenario as a DDL trigger on the subscriber will cause a snapshot to fail. This is something Microsoft are aware of but as yet have not come up with a solution