When deciding how frequently to dump the transaction log between database dumps, there are a couple of important points to consider. In the following example, assume a production application dumps its database at midnight every Friday, and transaction log dumps are performed every hour from 8 A.M. to 5 P.M. Monday through Friday, that is, 10 log dumps a day. If a failure occurs at 4:30 P.M. on Friday, resulting in the need to recover from backups, the previous Friday's database dump would need to be loaded, followed by 49 transaction log loads.
Although doing online log dumps results in a smaller performance hit to the SQL Server compared to database dumps, loading that many transaction logs can take a significant amount of time, resulting in a longer period of downtime. A better approach is to perform nightly database dumps and still perform hourly transaction log dumps during the day. Assuming the same scenario of a failure at 4:30 P.M. Friday, only Thursday night's database dump would need to be loaded, followed by the 9 hourly transaction log dumps from 8 A.M. through 4 P.M. on Friday.
Also consider that the larger the number of log dumps, the greater the risk of something happening to one of them. If any one transaction log dump is misplaced, deleted, or the transaction log truncated, no further transaction logs past that point can be loaded. Think of individual transaction logs as the pairs of teeth in a zipper. If one set of teeth is missing, you can only zip the zipper up to that point. Likewise, you can't skip over a missing transaction log.