More often than not, folks partition when they shouldn't.
Having separate partitions for C: and D: doesn't do anything for you in most cases. In most cases, folks end up with a C: drive that is too small in a year or two and they have to transfer the D: data somewhere external, fdisk the thing and re-size the partition or reload the OS onto one big C: drive single partition.
Linux/Unix can make some use of it ( "/" is /dev/sda1 and "/home" is /dev/sda2 for example), when you want to be able to have multiple different root systems and home remain consistent between them. Or similar applied uses.
SysAdmins and DBA's in a Windows environment might deliberately isolate D: from C: on the same physical disk or array so that if D: is filled up (a file share is 100% filled, or a database grows to consume the entire volume) it doesn't crash the server (servers don't like it when C: is full). But, more often than not, their original design called for separate physical volumes for C: and D: and for budgetary reasons they had to share a physical volume and turn it into multiple logical volumes to get the system stability issue of isolating a filled data volume from causing server crashes.
I say, unless you have a concrete, known reason why a physical disk needs to be partitioned into multiple logical volumes.... don't. The most common result is insufficient drive space on the C: drive from bad planning, or I/O bottlenecks from creating multiple logical volumes on a single large RAID5 array (rather than a RAID1 for C: and a smaller RAID5 or RAID1 for D:). You can even see head-seek I/O bottlenecks if you have a single drive evenly partitioned 50/50 for C: and D: on a SATA/IDE interface. Remember, this all traces back to a Cylinder/Head/Sector map on the drive and physical location on the platter. SATA/IDE drives cannot read asynchronously, so a single fetch operation has to complete for one file before the head can move on to the next file request (whereas SCSI/SAS drives can read asynchronously, and they can read portions of disparate files on in inbound swipe, then other portions of multiple disparate files on an outbound swipe and reassemble them in a faster operation). So, if the order of file reads is:
C:\Windows\player.exe
D:\FistfulsApp\fault.mp4
C:\Windows\always.dll
Then the head has to read 100% from the C: partition (the inner half of the disk), then the D: partition (the outer half of the disk), then the C: partition again (the inner half).
Whereas if it was all on the C: drive, it would merely be a function of how NTFS structured the files and if it was fragmented or not (which is also of issue in the C:/D: situation). The files are much closer together from a physical perspective on the disk and less movement is needed to retrieve them.
However, if they were separate physical drives... it would be scorchin' fast. The C: and D: reads would be happening at the same time since there are two heads to fetch the data.
Multiple volumes are an EXCELLENT thing to have. As long as they are on different physical disks or arrays.
