Добрый день, обращаюсь за вот какой помощью: нет ли у кого нибудь на примете хорошего материала, в котором бы описывались различные хорошие, правильные подходы к проектированию БД, не на самом базовом реляционном уровне, а скорей на уровне обсуждения неочевидных особенностей тех или иных стратегических позиций. Если что, собираюсь сдавать уже на MCITP по разработке, но уверенности в том, что "хоть прям щаз" смогу с чистого листа набросать хорошую систему, способную выдерживать хорошие нагрузки, такой вот уверенности нет совершенно никакой (отчасти потому что с хорошо спроектированными системами работать почти не приходилось, в основном выправлять чей-нибудь тихий ужас).

Вот например несколько почерпнутых из разных случайных источников советов, кажущихся мне правильными:

1. выбор поля для построения кластерного индекса
Разумеется он должен быть как можно более мелкий и всё такое. Но почти нигде не акцентируется внимание на том, что при выборе поля для кластеризации нужно исходить из соображений минимизации времени чтения с диска для типичных сценариев обращения к этой таблице. То есть, например, имеется табличка Products(ProductID, ManufactererId, ...) и в неких случайных коротких интервалах времени наибольшая нагрузка на систему за приходится на обслуживание запросов по одному производителю, то значит и кластеризовать нужно по ManufactererId, чтобы за одну операцию дискового чтения подтянуть смежные страницы с продуктами этого производителя и оперировать ими уже дальше в оперативной памяти на всё время текущей активности. Если типичные сценарии обращений будут другими, то и выбор поля для кластерного индекса будет другой какой-нибудь.


2. Вертикальное разделение таблиц
Понимание необходимости пришло во время работы с сильнонагруженной OLTP. Если есть табличка Row(A, B, C, D, E), в которой (A, B, C) - практически никогда не изменяются за всё время существования записи, но зато в (D, E) происходят постоянные апдейты изменения текущих статусов, то имеет смысл разделить таблички на две Row(PK, A, B, C) и Urgent(FkRow, D, E), чтобы все эклюзивные блокировки приходились на вторую таличку Urgent, а первая была всегда доступна на чтение при любых уровнях изоляции.


Ну в общем такие вот вещи активно интересуют. Может быть, хотя бы не анализом настоящей работающей системы (настоящую оттюненную никто конечно же не покажет), так хотя бы чтением чужих умных мыслей набраться какого-то понимания ценных практических правил проектирования на движке SQL Server. Ну или какой-нибудь более глобальный объемлющий материал, понятный девелоперу. А то как каждый винтик по отдельности крутится вроде бы понимаю, но как их в единую большую хорошую систему все собрать пока что не сказать, чтобы с уверенностью понимаю.

alexeyvgВ BOL кроме описания команд есть масса текста.

Ещё пример ресурса - http://sqlcat.com/
Там есть материалы и на русском языке.

Это всё, конечно так. Масса коротких статеек, которые вроде читаешь и всё понятно, всё логично, поскольку разными словами часто пишут об одном и том же, то всё в том или ином виде было давным давно прочитано, то есть новых истин никаких не открывается. Но вот понимания целостности знаний нет почему-то. Может быть какой-нибудь объемный талмуд есть в авторстве какого-нибудь известного гуру, который может как-то помочь систематизировать знания хотя бы?

В общем ушёл гуглить паттерны проектирования бд, авось что-нибудь выловится...