Ok, you really need to head over to the documentation and read it - become a small dba. Expecting people here to copy / paste the EXTREMELY detailed information from BOOKS ONLINE - the SQL Server documentation - is not good behavior. That said, you also areon the wrong site - this is so absolutely NOT a programming issue. There is a sister site (serverfault.com) for server operational issues, which backups belong to.
To get you started:
The transaction log records all changes done to the Database. THis means you take a full backup, then the tx log can be used to roll that forward up to THE LAST TRANSACTION BACKED UP IN THE LOG. MEans that if you take a backup of the tx log afte 16 hours, the server dies, on the new server you restore the daily backup, then process the transaction log and are back to the last commited transaction after 16 hours ;) If you ask me - a business not doing that deserves the damage they get from not doing that.
The transaction log actually is the HUGH advantage you have in something like SQL Server compared to classical file level backups.
All other questions I can not answer. Seriously. These are not "dba level" decisions, they are business decisions. I know companies doing transaction log backups every 5 minutes, shipping them over to a seaprate server (check: Log File Shipping). Reason: Loosing data would be a desaster. Imagine Amazon loosing all sales for half a day. I know other businesses doing daily, sometimes even weekly backups (small shop, intranet site). I know others not relying on backups for desaster issues, but using replication and / or mirroring, with daily full backups and hourly log backups, so that if a server dies, they dont get any downtime. All this is "the same" from a technical point of view - every recommendation depends on the business case, which you say nothing about.
As a normal scenario I would suggest regular full backups (weekly, during off time like sunday), daily differential bakups (a lot smaller than the full one) and then a log backup every x hours (1, 6, 12 - depends on your business case).