Я разрабатываю решение для отчетности, которое использует SQL Server 2008 R2 в качестве базовой базы данных. Схема базы данных довольно проста. Одна таблица с именем Calls с CallId ПК и одна таблица с именем Events, которая имеет связь внешнего ключа с вызовами fk_CallId.Улучшение производительности базы данных SQL Server
Каждый звонок имеет не менее 6-7 событий, и в день регистрируется 3000 + звонков.
Я немного обеспокоен тем, насколько сильно это отношение оказывает на производительность запросов. Если использовать inner join на столе с более чем двумя миллионами строк (Events), это сильно ухудшит производительность, я могу добавить поле CallerId в таблицу Events. A не использовать объединения (хотя я потеряю и другую информацию о связанных Calls Таблица).
В общем, Есть ли еще один шаг, который я могу сделать, чтобы убедиться, что производительность в порядке?
Через 100 лет у вас будет около 100 миллионов строк в вашей базе данных. Поскольку это все еще база данных среднего размера, на данный момент я действительно не буду беспокоиться о производительности. Ключ здесь - убедиться, что вы правильно индексировали ваши таблицы (и работали на достойном аппаратном отключении). –
@Lieven: Спасибо за комментарий. однако, как я прокомментировал ответ Олега, моя оценка составляет 7 000 000 + строк в таблице «событий» каждый год. – Kamyar
, тогда это станет 700 миллионов строк ** через 100 лет **. Мой первоначальный комментарий все еще применяется. Хотя я, конечно, рекомендую подумать об оптимизации, убедитесь, что вы не стали жертвой [преждевременной оптимизации] (http://www.google.be/search?q=premature+optimization&ie=utf-8&oe=utf-8&aq=t&rls= org.mozilla: нл: официальный и клиент = светлячок-а). –