Я обычно использую индексированное представление для такого рода вещей. Это позволяет вам денормализовать данные для быстрого поиска, но у них нет возможности выйти из синхронизации. Люди также не будут смущены и думают, что представление является хозяином данных. В основном я использовал стандартный sku SS2K5, поэтому мне нужно указать подсказку (noexpand), чтобы он фактически использовал индекс в представлении (предприятие сделает это автоматически). Таким образом, для стандартного sku я всегда создаю представление обертки, к которому обращаются все, поэтому я знаю, что подсказка всегда на месте.
Кодирование этого на веб-странице, так что, надеюсь, нет синтаксических ошибок;)
create view postCount__
as
select
threadId
,postCount=count_big(*)
from thread
group by threadId
go
create unique clustered index postCount__xpk_threadid on postCount__(threadId)
go
create view postCount
as
select
threadId
,postCount=cast(postCount as int)
from postCount__ with (noexpand)
go
Таким образом, я использую номенклатуру в фактическом индексированном представлении, чтобы все знали, чтобы не запрашивать его напрямую. Вместо этого они ищут связанный вид оболочки, который применяет подсказку noexpand. Использование индексированного представления вынуждает вас делать count_big, поэтому я часто обращаюсь к int в представлении оболочки, чтобы иметь возможность лениво сохранять наш код asp.net, используя 32-битные числа. Было бы лучше опустить актерский состав, но это не оказало для меня существенного влияния.
РЕДАКТИРОВАТЬ - Я могу вам сказать, что программное обеспечение форума всегда денормализует количество сообщений в таблице потоков. Это убивает БД, чтобы постоянно подсчитывать количество сообщений на каждом просмотре страницы, если у вас есть активный форум. Мне нравится, что в mssql есть индексированные представления, поэтому вы можете декларативно определять денормализацию, а не поддерживать ее самостоятельно.