what I've implemented before as our standard SQL Server setup/backup procedures (SQL 2000-2008) is as follows
Data Partitioning Split the OS/SQL binaries, Data files and Log files onto 3 separate physical volumes, OS/SQL on RAID 1, Data on RAID 1 (This update following comment from Paul Randall (http://www.sqlskills.com/), Logs on RAID 1. Also recommend 1-2 hot spares.
I would recommend at least some level of RAID for them all wherever possible but if space/cost is an issue, RAID 1 and place them all on the one set of drives, you'll still have the same level of redundancy (max of 1 drive fail) as RAID 5 (assuming 2 and 3 drives respectively)
Database Setup Implement 3 data files for each your databases, the default MDF and LDF for data and logs and also an NDF, set the NDF as your default data file in your database properties, leave the MDF alone. I've set all my databases to the Full Recovery Model as I do mirroring and need to be able to do point-in-time restores. I would recommend doing this anyway but it does come with a warning (below)
BACKUPS The single most important part of your database setup is getting your backups (and associated restores) correct. My standardised setup is a Full backup @2am when we have a narrow window of people not using the databases (global operation with staff in multiple timezones from Singapore to New York) then a transaction log backup every 5 hrs starting @ 8am (0800, 1300, 1600, 2100). Disclaimer Make damn sure that if you have your databases set to Full Recovery Model that you are doing Transaction Log Backups otherwise you can end up with monstrous log files and then you might have to truncate and then shrink them, which according to Paul Randall (Hi Paul!), who I would trust implicitly relating to SQL, is aVeryBadThing(tm). The daily backups (including the transaction logs relating to them) are kept locally to the machine then scooped up nightly by our backup service and taken offsite by the admin on duty. This way if the machine is lost we lose only the data from the last full backup and in the case of someone screwing up the data, only the information input between the last T-Log backup and that point in time (we can go into the current log and playback any other transactions but we usually don't as our SLAs are built to accomodate this) You can of course send the transaction log backups off machine or even off site at the time of creation but that's a decision for you to make.
Data File Shrinking DON'T DO IT (unless you get into a situation where you can't avoid it) Certainly don't go scheduling it!
Indexing and Fragmentation This should be a manual (but scripted) operation that is carried out only when required, you should be doing regular maintenance and index fragmentation should be on this list. On my monthly plan I check the sizes of the data files, the index fragmentation and the number of databases (we sometimes have developers add databases and not tell us, the maintenance plans take care of the backups but sometimes they screw up the data file layouts and naming conventions), if we detect any new databases they get audited with respect to their size, data file layout and backups (never hurts to check and double check backups)
Please feel free anyone, to pick holes in the above or at least to tell me that I'm talking nonsense.