Запросы соединения и когда это слишком много
Я нахожу, что использую много запросов соединения, особенно для получения статистики о пользовательских операциях от моей базы данных. Запросы как это весьма распространены:
from io in db._Owners where io.tenantId == tenantId
join i in db._Instances on io.instanceId equals i.instanceId
join m in db._Machines on i.machineId equals m.machineId
select ...
Мое приложение все еще не активно, таким образом, у меня нет способа судить, будут ли эти запросы в вычислительном отношении препятствовать в реальной жизни. Мой запрос:
- Существует ли предел тому, когда выполнение слишком многих 'соединений' слишком много, и это может быть описано, не получая реальную жизнь операционная статистика?
- Каковы мои альтернативы? Например, лучше просто составить дополнительные таблицы для содержания статистических данных, которые являются, я обновляю, когда я иду, вместо того, чтобы сплотить различные источники таблицы каждый раз, когда я хочу статистику?
3 ответа
Если у вас нет информации о производительности, не выполняйте оптимизацию.
Преждевременная оптимизация - корень всех зол.
1) Я не думаю, что вы когда-нибудь дойдете до «предела». 2) Это называется деномализацией, преждевременная денормализация - это просто напрасная трата усилий, если вы не знаете, существует ли проблема.
Я бы сказал, что ваш запрос выглядит вполне нормально.
1) Есть ли предел, когда слишком много "соединений" - это слишком много
Нет, количество соединений - это не проблема, а структура данных в каждой таблице, наличие и использование индексов и то, что нужно сделать, чтобы получить данные.
Нормализованные данные обычно являются основной целью при проектировании реляционных БД. Денормализация обычно рассматривается как средство оптимизации запросов только по мере необходимости из-за дополнительных усилий, необходимых для поддержания согласованности данных.
Если вы действительно обеспокоены, опубликуйте свою модель данных ERD (таблицы базы данных и как они связаны между собой) и базу данных, которую вы используете для проекта (потому что не все базы данных одинаковы).
Если у вас не очень высокий трафик, правильно настроены индексы и т. Д., У вас не должно возникнуть проблем.
Для отчетов / анализа в некоторых местах создается хранилище данных , которое в своей основной форме является [частично] денормализованной копией вашей основной базы данных. По ним легче составлять отчет, поскольку одна таблица обычно содержит большую часть, если не все, данных, необходимых для отчета. Их также может быть намного быстрее читать, поскольку вам не нужно так часто присоединяться. Однако им потребуется больше места на диске (дублированные данные). Если записи разрешены, они будут медленнее (придется обновлять все дублированные данные), и у вас возникнет проблема с сохранением согласованности этих дублированных данных.
Другими словами, если вы не выполняете только отчеты (или доступ только для чтения), сохраняйте объединения.