Trigger:

Salesforce Articles:

https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_bestpract.htm


Best Practice #5: Streamlining Multiple Triggers on the Same Object

It is important to avoid redundancies and inefficiencies when deploying multiple triggers on the same object. If developed independently, it is possible to have redundant queries that query the same dataset or possibly have redundant for statements.

Note that it is very important to detail exactly how governor limits are applied when multiple triggers are deployed on the same object. For starters, you do not have any explicit control over which trigger gets initiated first. Secondly, each trigger that is invoked does not get its own governor limits. Instead, all code that is processed, including the additional triggers, share those available resources.

So instead of only the one trigger getting a maximum of 100 queries, all triggers on that same object will share those 100 queries. That is why it is critical to ensure that the multiple triggers are efficient and no redundancies exist.

http://wiki.developerforce.com/page/Apex_Code_Best_Practices

http://developer.force.com/cookbook/recipe/trigger-pattern-for-tidy-streamlined-bulkified-triggers



Blogs:

Triggers

There should only be one trigger for each object.
Avoid complex logic in triggers. To simplify testing and resuse, triggers should delegate to Apex classes which contain the actual execution logic. See Mike Leach’s excellent trigger template for more info.
Bulkify any “helper” classes and/or methods.
Trigers should be “bulkified” and be able to process up to 200 records for each call.
Execute DML statements using collections instead of individual records per DML statement.
Use Collections in SOQL “WHERE” clauses to retrieve all records back in single query
Use a consistent naming convention including the object name (e.g., AccountTrigger)

http://blog.jeffdouglas.com/2010/10/21/force-com-programming-best-practices/

Within an Apex Trigger context, the Force.com governor limits are currently too low to directly invoke many of the FinancialForce APIs successfully, especially when considering bulk record operations on custom objects. To avoid hitting governor limits, consider starting a background Batch Apex job from the trigger instead. However, be warned, as per the Apex Developer’s Guide, the platform limits the number of concurrent Batch Apex jobs queued per org to five. Once this is reached, the Database.executeBatch method will throw an exception and the records associated with the given trigger invocation will not be inserted. The advice from Salesforce is that the developer needs to take great care to consider this constraint if using Batch Apex from a trigger. The advice from FinancialForce.com is to avoid this approach, and instead consider using the new Spring '10 Scheduler or a button to invoke a Batch Apex job. Only consider using Batch Apex from a trigger if you are 100% confident you understand the implications. Specifically, that you have put in place adequate error handling and recovery, have volume tested, and ideally have control of the means by which your users manage records for the custom object associated with the trigger.

http://developer.financialforce.com/technical-reference/best-practice/

http://salesforcedeveloperblog.blogspot.in/2011/05/best-practices-of-triggers.html

http://www.iterativelogic.com/salesforce-apex-trigger-best-practices/


Regards,
Ashish