SQL Server Partitioning vs Indexes on Separate Filegroups I am just about to start on an excercise to reorganise a partitioned table and I was looking for best practises or recommendations.

Let us say I have a billion row table and 8 logical disks available to me for this table. 

The question I have is, is it better to create a partition scheme which divides the data into 8 filegroups and has the indexes storage aligned with the data... 

Or would it be better to create 4 file groups for data and 4 for indexes (not aligned), then place each of the filegroups onto one logical disk?

Any suggestion or comments would be welcome.
First and foremost: those logical disks better be backed by at least 8 different physical disks. If you're asking about load balancing 8 logical disks created on the same physical storage (the same spindles) then you're wasting time.

The best (and simplest!) option is to create a single filegroup with 8 files (equal in size and pregrown), each on a spindle, and then place the table and the indexes in this filegroup. SQL Server will balance the data equally among the files.

Partitioning is a feature for ETL switch in and switch out. It should not be used for performance, as the best you can hope for is equal performance with the original table. For performance use a well designed clustered index, one that matches the typical load.

If your data is really known upfront and the index usage characteristics are very well understood then you may try to balance them explicitly on their own filegroups. But trying to wrestle manual control over this is more likely to cause harm than benefit. The simpler option of single file group with 8 files balances IO better than manual explicit control 99% of the times.