Sql-server – Best practices for creating partition schemes and functions

I can't give you an answer to question 1).
But to answer question 2):
What you are requesting is known as the "sliding window scenario".
If you want to eliminate a partition containing data that is no longer needed you have to perform following steps:

• Create a table on the same filegroup as the partition you want to delete (typically, this table is referred to as a staging table).
  This table has to have exact the same structure as the partitioned table, including indexes.
• Switch the partition to the staging table
• You have to remove the reference to the filegroup from the partition function vie MERGE RANGE ...
• Now you can truncate the staging table and drop it. What is left is an empty filegroup you can remove, too.

Some more details on this at http://technet.microsoft.com/en-us/library/aa964122.aspx and the white paper on partitioning, available under http://msdn.microsoft.com/en-us/library/dd578580%28v=sql.100%29.aspx.

I'm going to assume that, as TomTom went through in detail, some of your hardware acronyms are incorrect regarding your actual server (which you apparently already have).

I'm also assuming that your reference to a "75GB database" indicates you have one database of 75GB that's your primary DB. This should have only one log file.

Assuming you have 8 disks on modern hardware, one generalized maximum performance setup would be: 2 drives in RAID1 (mirroring) for OS 4 drives in RAID5 for all data files and most log files other than the primary DB's log file. 2 drives in RAID1 (mirroring) for your primary DB's log file.

RAID5 is surprisingly fast on modern hardware, and 4 disks in RAID5 gives 3 disks worth of storage.

The primary DB's log file is by itself so that it really is sequential access - it should be the only file on that entire raidset. If you had many log files, the drive heads would have to jump from one to the other, which is not sequential.

On reading the additional information in the updated question: a 72GB SAS drive clearly cannot hold a 75GB database even without accounting for growth. Either a 3 or 4 drive RAID5 or a 4 drive RAID 10 is the bare minimum, given the new hardware information. For any one specific case, try a few configurations and benchmark them - but with 64GB of RAM on a 75GB database, I'd expect almost the entire database to be in buffer, rendering disk performance much less important; write performance for the transaction log will be one of the first things to watch.