А речь не о виртуалке, случайно?
Потому что в случае виртуалки - приоритеты в другом.
И потом, о каком разбиении идет речь?
Это будут отдельные логические диски в пределах одного виртуального тома? Отдельные виртуальные тома?
Что для вас "диск"?

Значтица так. Мне, как админу, это близкое и родное, поэтому отвечу развернуто:
а). Если речь идет о виртуальной машине:
Всё зависит от того, как, в каком месте, будут расположены файлы с вашими дисками.
Разделять всё по дискам имеет смысл только в том случае, если вы этот вопрос - контролируете.
Например, в состоянии разместить какой-то файл (диск) на быстром ресурсе, какой-то - на медленном и т.д.
Если вы этот вопрос - не контролируете, и никак не можете управлять, например, минимальным количеством iops количеств к вашему файлу с диском - просто забейте на всё, и заведите два файла - один с диском под систему, второй - подо всё остальное.
На что обратить внимание:
1. Крайне желательно, чтобы файл с диском был не динамически расширяемым, а фиксированного размера.
2. Крайне желательно, чтобы на него не распространялась политика фоновой дедубликации, которую включают на уровне ресурса хранения данных (ну, дисковой полки).
3. Крайне желательно, выбить из админов виртуальной среды ограничение по минимальному количеству iops к вашему файлу.
Учтите, что одна операция вставки, удаления, модификации данных - требует как минимум 2 io операции на файле, в котором хранятся логи. Поэтому, например, если у вас минимальное количество операций на томе, где лежат логи - 300 iops (соответствует одиночному шпиндельному диску) - вы сможете вставлять/обновлять данные чуть больше 150 раз в секунду.
4. Поэтому, если количество операций ввода вывода контролируется не для всей ВМ целиком, а для ее отдельных виртуальных дисков - выносите логи в отдельный файл/диск, и выбивайте на нее максимальную квоту на io.
5. Данные, как не странно, менее зависимы от iops, для них важнее пропускная способность. Чем больше мегабайт в секунду, тем лучше.
Промежуточный вывод:
Если размещаетесь на ССД ресурсе, с его космическими iops-ами, забейте на всё, и держите всё (ну, кроме системы) - в одном файле/диске. Только tempdb ограничьте, чтобы всё место не сожрало и всё.
Если ресурс гибридный, и всё не влазит, то логи, tempdb - на ССД или 10К, а данные вполне поживут на 7200. Если вариант с претензией на богатство - порежьте данные на горячие/холодные, и файловые группы с горячими данными - тоже, вслед за логами, переместите на ССД ресурс.

б) Если речь идет о системе, имеющей физический доступ к подсистеме хранения, и вы контролируете разбиение подсистемы хранения на тома, диски энд етц, т.е. "железной"
1. Вариант "совсем по богатому": Система, данные, логи, tempdb, оперативный бэкап (если база маленькая) - на отдельных дисках, размещенных на разных томах рэйд контроллера .
Промежуточный вывод-2:
Если у вас один виртуальный том на рэйд контроллере, например все 8 дисков завернуты в RAID10, или, не дай бог, в RAID6, а поверх этого вы выделяете логические диски - то это целиком ситуация из предыдущего параграфа.
Не парьтесь. Разбейте всё на 2 диска, система - данные, ограничьте темпдб, и нефиг огород городить.
Всё даже хуже, чем в виртуальной среде, потому что если вы, например, выделите отдельный логический диск под логи - минимальное количество iops вы для него на уровне виртуального тома рэйд контроллера - не вырежете.
Так что оно будет делить иопсы сразу со всей нагрузкой. И если это шпиндели, то максимум иопсов, которые у вас будут - 1000. Ну, 4000, если всё совсем замечательно. Вообще на всё-всё-всё. На систему, данные, логи, темдб, бэкапы. Поэтому см. выше про обновления.
2. Однако если вы контролируете нарезание батона, то правила - прежние:
- логи на ресурсы с минимальной латентностью, максимальными иопсами.
- данные - фиг с ними, с иопсами, могут и на рэйд-6 пожить.
- темпдб - можно даже на одиночном ссд разместить, или на паре дисков в страйпе, без избыточности (ну, правда оно когда-нибудь аварийно встанет, и вам отвесят пендель). Поэтому лучше без экстремизма, на рэйд10 или на зеркало из ССД.

А вот сколько при этом будет дисков, как они будут называться, и как будут видиться в системе - имеет чисто эстетическое значение.
И чем больше разбиение - тем больше геморроя потом :-)

Всё целиком ИМХО, как говорится.
Открыт для замечаний и всё такое.

Владислав Колосовtrew,

не забудьте отформатировать 64к на кластер.
Ага, и выключить виндовое индексирование на томе, где будут данные.
А если у вас есть Filestream - то до кучи еще отключить генерацию 8.3 имен и last access time.
Кстати, почему то в гайде, который дал Minamoto - этого нет.