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 that a production application dumps the database at midnight every Friday and that transaction log dumps are performed every hour from 8 a.m. to 5 p.m. Monday through Friday (10 log dumps per 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 do nightly database dumps and still do 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 bigger the risk of something happening to one of them. If any one transaction log dump is misplaced or deleted, or if the transaction log is 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.