Присоединяйтесь к запросам и когда это слишком много - PullRequest
6 голосов
/ 01 июля 2010

Я обнаружил, что я использую много запросов на присоединение, особенно для получения статистики о пользовательских операциях из моей базы данных.Подобные запросы не редкость:

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 ...

Мое приложение все еще не активно, поэтому я не могу судить, будут ли эти запросы вычислительно запретительными в реальной жизни.Мой запрос:

  1. Есть ли предел, когда слишком много «объединений» является слишком большим, и это можно описать, не получая реальной рабочей статистики?альтернативы?Например, лучше ли просто создавать дополнительные таблицы для хранения статистики, которую я обновляю по мере движения, а не собирать разные источники таблиц каждый раз, когда мне нужна статистика?

Ответы [ 3 ]

13 голосов
/ 01 июля 2010

Если у вас нет информации о производительности, не оптимизируйте.

Преждевременная оптимизация - корень всего зла.

1) Я не думаю, что вы когда-либо достигнете "предела". 2) Это называется деномализация, преждевременная денормализация - это просто напрасная трата усилий, если вы не знаете, существует ли проблема.

Я бы сказал, что ваш запрос выглядит вполне нормально.

0 голосов
/ 01 июля 2010

Если у вас не очень высокий трафик и индексы не установлены должным образом и т. Д., У вас не должно быть проблем.

Для отчетов / анализа в некоторых местах создается хранилище данных , котороев самой основной форме это [частично] денормализованная копия вашей основной базы данных.О них проще сообщать, поскольку в одной таблице обычно содержится большинство, если не все, данные, необходимые в отчете.Они также могут быть намного быстрее читать, так как вам не нужно так много присоединяться.Однако им потребуется больше дискового пространства (дублированные данные).Если записи разрешены, они будут выполняться медленнее (придется обновлять все дублированные данные), и у вас возникнет проблема обеспечения согласованности этих дублированных данных.

Другими словами, если только вы не делаете отчеты(или доступ только для чтения), сохраняйте объединения.

0 голосов
/ 01 июля 2010

1) Есть ли предел тому, когда слишком много «объединений» слишком много

Нет, количество объединений не так важно, как структураданные в каждой таблице, наличие и использование индексов и то, что нужно сделать, чтобы получить данные.

Нормализованные данные обычно являются основной целью при проектировании реляционных БД.Обычно вы рассматриваете денормализацию как средство оптимизации запросов только по мере необходимости из-за дополнительных усилий, необходимых для поддержания согласованности данных.

Если вы действительно обеспокоены, опубликуйте свою модель данных ERD (таблицы базы данных и их взаимосвязь)и база данных, которую вы используете для проекта (потому что не все базы данных одинаковы).

...