Multiple triggers vs a single trigger Scenario:

Each time data is inserted/updated/deleted into/in/from a table, multiple unrelated items of business logic need to be executed.

Question

Given that the solution is to use database triggers, which option is better?:

1) A single trigger per operation (insert/update/delete):


I_Table - executed on an insert
U_Table - executed on an update 
D_Table - executed on a delete


Each trigger would handle multiple unrelated items of business logic.

OR

2) Multiple triggers per operation that were segregated by concern:


I_Table_Logging - for logging on an insert
I_Table_RI - for enforcing referential integrity on an insert
I_Table_BL - for executing business logic on an insert
U_Table_Logging - for logging on an update
U_Table_RI - for enforcing referential integrity on an update
U_Table_BL - for executing business logic on an update
D_Table_Logging - for logging on an delete
D_Table_RI - for enforcing referential integrity on an delete
D_Table_BL - for executing business logic on an delete


I prefer option 2 because a single unit of code has a single concern.  I am not a DBA, and know enough about SQL Server to make me dangerous.

The architecture and schema of the database must not be changed.  There are several places in the schema that should be enforced with explicit relationships, but unfortunately cannot be changed yet.  That is the reason I need to manually enforce referential integrity instead of relying on an explicit relationship.

Are there any compelling reasons to handle all of the concerns in a single trigger?  I'm specifically concerned about performance, order of execution, and rollback.
My personal preference is to create triggers by functionality, not by DML operation. So I have one handling auditing for insert/update/delete, one doing some kind of business rules or referential integrity (again, for insert/update/delete), another doing some ugly hack to work around undesirable behavior in our client software (possibly only for insert or update), etc.

Keeping each "behavior" in one place reduces the chances of forgetting to update logic that's been duplicated across three separate insert, update, and delete triggers.

The biggest pitfall with triggers is that the INSERTED and DELETED tables are not indexed, and you can't index them directly. Joining them against large data sets performs horribly, and things get really out of hand when you've got many triggers on a table, especially when trigger cascading starts coming into play.

Most triggers I write start out by creating table variables @i and @d with the columns from INSERTED and DELETED that will be needed, giving them both a clustered primary key (since that's the only way you can index a table variable), then filling them with the data from INSERTED and DELETED.

I wrote a short (noncommercial) article about triggers, and it also covers a few other points.

http://dave.brittens.org/2012/03/29/writing-well-behaved-triggers/