Разочарование от обобщений

Автор: Paul Randal, The frustration of sweeping generalizations – follow on from Search Engine Q&A #12

Постоянное участие в дискуссиях побудило меня высказать свои мысли о многочисленных обобщениях, которые преследуют индустрию и иногда затрудняют дачу советов на форумах и в блогах. 

Некоторые примеры вопросов, которые порождают обобщения:

• Следует ли создавать кластерные индексы для всех таблиц? (Известный спор о кластерных индексах, как его любит называть Кимберли.)
• Следует ли перестраивать или реорганизовать индексы для устранения фрагментации?
• Какое решение высокой доступности следует использовать?

Проблема — как и с большинством советов — в том, что крайне сложно делать обобщения. Это связано как с тем, что без большого количества доказательств многие люди (вполне обоснованно) не верят обобщениям, поскольку они могли обжечься на одном из них в прошлом, так и с тем, что почти каждая ситуация уникальна, поэтому многие обобщения бесполезны.

Я бы хотел, чтобы люди предоставляли обоснование обобщений, а также некоторое представление об исключениях и обстоятельствах, при которых они возникают.

Что касается этого случая (следует ли создавать несколько файлов из-за наличия нескольких ядер/ЦП), я думаю, мы уже исчерпали эту тему. Обобщения здесь таковы:

• Для баз данных, не являющихся tempdb, обычно не нужно создавать несколько файлов, если только у вас нет очень высококлассной рабочей нагрузки определённого типа (редкость).
• Для tempdb обычно нужно, если ваша рабочая нагрузка оправдывает это на многопроцессорном/многоядерном сервере.
• Поставщики ввода-вывода могут рекомендовать это для увеличения пропускной способности ввода-вывода на их конкретном оборудовании.
• Существуют обобщения из различных источников, которые оспаривают всё вышеперечисленное.

К сожалению, вы не получите окончательного, авторитетного ответа на такой вопрос проектирования или стратегии, и вы будете продолжать находить противоречия всему, что кто-либо говорит на форумах, и даже Microsoft противоречит сама себе.

Я бы предложил следующее:

1. Следовать мнению большинства ответов на заданные вопросы, основанному на коллективном опыте респондентов с большим количеством клиентов, баз данных и рабочих нагрузок.
2. Провести собственное тестирование на своём оборудовании, со своей рабочей нагрузкой и посмотреть, что работает для вас (но будьте осторожны: тестирование в вакууме может доказать или опровергнуть всё, что вы захотите — именно поэтому вы видите так много противоречивых утверждений).

И последнее замечание о Microsoft: это очень большая компания с множеством групп. Любой может спонсировать технический документ, написать статью в блоге/статью на MSDN/TechNet и опубликовать её, или ответить на форуме как заметный сотрудник Microsoft, и это будет иметь «официальный штемпель» Microsoft. Когда я был в группе продуктов, я постоянно был обескуражен дезинформацией, плохими советами, противоречиями и безосновательными утверждениями, которые я видел от сотрудников Microsoft, которые просто пытались быть полезными.

Как только что-то опубликовано в интернете, невероятно трудно исправить нанесённый ущерб. На форумах и в группах новостей иногда существует фундаментальный элемент недоверия, который может быть утомительным, когда вы пытаетесь помочь людям. Может быть очень трудно убедить людей, что чей-то совет не лучший для выполнения — я помню несколько случаев, когда я спорил с людьми о том, как работает CHECKDB или что означает сообщение об ошибке повреждения, и в итоге мне приходилось прибегать к фразе «Я писал этот код — боюсь, вы неправы», что я очень не люблю делать.