Лучше всего оптимизируя для большой таблицы SQL Server (записи на 100-200 миллиметров)

Практическое правило: если таблица будет содержать более 25 миллионов записей, вам следует рассмотреть возможность секционирования таблицы (и индекса), но эта функция доступна только в редакции SQL Server Enterprise (и, соответственно, редакции для разработчиков).

Поскольку вы не указали цель базы данных или требования, вот некоторые общие вещи, в произвольном порядке:

1. Малые кластерные индекс по каждой таблице. Подумайте о том, чтобы сделать его своим первичным ключом для каждой таблицы. Это будет очень эффективно и сэкономит место в основной и зависимых таблицах.
2. Соответствующие некластеризованные индексы (по возможности охватывающие индексы)
3. Ссылочная целостность
4. Нормализованные таблицы
5. Согласованное именование всех объектов базы данных для упрощения обслуживания
6. Соответствующее разбиение (таблица и индекс), если у вас есть Enterprise Edition of SQL Server
7. . Соответствующие ограничения проверки таблиц, если вы собираетесь разрешить прямое манипулирование данными в базе данных.
8. Решите, где будут действовать ваши бизнес-правила, и не отклоняйтесь от них. В большинстве случаев они не входят в базу данных.
9. Запустите Query Analyzer для часто используемых запросов (как минимум) и поищите просмотры таблиц. Это убьет производительность.
10. Будьте готовы к тупикам. С базой данных такого размера, особенно если будет много записей, тупиковые ситуации вполне могут стать проблемой.
11. Воспользуйтесь широкими преимуществами представлений, чтобы скрыть сложность соединения запросов и потенциал для оптимизации запросов и гибкой реализации безопасности.
12. Рассмотрите возможность использования схем для лучшей организации данных и гибкой реализации безопасности.
13. Познакомьтесь с Profiler. Имея базу данных такого размера, вы, скорее всего, потратите некоторое время на поиск узких мест в запросах. Здесь вам может помочь Profiler.