Семь внутренних объединений в запросе слишком много?
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
14 ответов
это не неслыханно, но я поместил бы его в представление для простоты использования и обслуживания
Два вопроса:
- это работает?
- можно ли объяснить это?
Если так, затем семь прекрасен. Если Вы не можете объяснить запрос, то семь слишком многие.
Нормально, если Ваша схема находится в 5-я нормальная форма :)
В зависимости от того, что Вы пытаетесь выполнить, большое количество участвует в запросе, не замечательно.
Лично, я был бы менее обеспокоен количеством соединений, используемых для возврата желаемого набора результатов и более соответствующий с тем, оптимизирован ли запрос и работающий в приемлемых параметрах.
, Если запрос полностью оптимизирован и не может быть обрезан вниз, но сам запрос не выполняется достаточно быстро затем, возможно, что дизайн структуры данных не является правильным соответствием с тем, что Вы пытаетесь сделать. В которой точке можно переоценить то, что Вы пытаетесь выполнить или структура данных, которые подают Вашу бизнес-модель.
Это нисколько не необычно. С системой как Siebel распространено видеть, присоединяются к количествам в двузначных числах.
Это, вероятно, не нормально, но это, конечно, не чрезмерно. Если Вы присоединяетесь к тем же таблицам много раз, создаете некоторые представления.
Семь соединений делают, это более жесткий для удобочитаемости, но более важный является производительность и масштабируемость. Если они в порядке, пойдите для него.
количество соединений зависит от Вашей модели данных, 7 соединений могут быть в Вашем запросе, если, именно это Вы запрашиваете для - я вспоминаю имеющие подобные запросы в приложении, я продолжил работать давным-давно, производительность зависит от многих факторов (размер таблицы, индексы, загрузка сервера, конфигурация сервера для именования немногих), и я не думаю, что это может быть обобщено, что 7 соединений плохи.
, если это работает на Вас затем, я предполагаю его штраф :D
Да, это нормально - но, действительно, это не такая прекрасная идея с точки зрения производительности. Так как планы запросов основаны , оценил затраты, существует увеличение количества ошибок , поскольку Вы увеличиваете соединения (или любой другой оператор, в этом отношении):
Оптимизатор запросов SQL Server оценит минимум одной строки, выходящей из искать оператора. Это сделано для предотвращения случая, когда очень дорогое поддерево выбрано из-за недооценки кардинальности. Если поддерево, как оценивается, возвращает нулевые строки, много стоимости планов о том же и могут быть ошибки в выборе плана в результате. Так, you’ll замечают, что оценка является “high” для этого случая, и могли закончиться некоторые ошибки. Вы также могли бы заметить, что мы оцениваем 20 выполнения этого ответвления вместо фактических 10. Однако, учитывая количество соединений, которые были оценены перед этим оператором, являющимся прочь фактором 2 (10 строк) isn’t считал слишком плохо. ( Ошибки могут увеличиться экспоненциально с количеством соединений ).
кроме того, оптимизатор пытается сбалансировать время, требуемое придумать план по сравнению с потенциальными сбережениями - он не потратит весь день попытку найти самый оптимальный план. Чем больше соединений, тем больше количество альтернативных планов существует - некоторые из которых могут быть более оптимальными, чем оптимизатор, имеет время для нахождения.
7 прекрасен, если Ваше проектирование баз данных требует его. Однако, если бы 7 необходимо для достижения цели, я вновь исследовал бы проектирование баз данных, чтобы удостовериться, что этот уровень мрака действительно необходим.
Из любопытства, этот DB2? Просто шаблон я заметил :)
это - 7 внутренних объединений на той же таблице, 7 внутренних объединений на различных таблицах, или 7 вложили внутренние объединения?
... вопрос о приеме! Действительно не имеет значения, если, именно это Ваша структура базы данных требует, затем это корректно
протест: если это - 7 вложенных внутренних объединений на той же таблице, у Вас, вероятно, есть плохо структурированная таблица ;-)
7 или еще больше нисколько не необычно в хранилищах данных, где таблица фактов могла легко иметь внешние ключи к дюжине размеров. В сценарии хранилища данных кардинальность размеров является обычно низкой по сравнению с таблицей фактов, таким образом, фильтры на размерах помогают таблице фактов быть использованными через индекс, ищут или сканируют.
Для нормализованной транзакционной схемы, это обычно не проблема, если кардинальность набора результатов является низкой в основной базовой таблице (т.е. выберите все об одном клиенте), потому что внешние ключи могут обычно просто приводить к индексу, ищет или индексные сканирования.
Это, конечно, весьма обычно. Однако, по крайней мере, в Oracle, 7 специальное число, поскольку больше, чем это и оптимизатор больше не может тестировать каждый порядок соединения (из-за факториального роста в количестве возможностей). Таким образом, было бы мудро постараться не переходить 7, если Вы не готовы нянчить свой план выполнения.
Я думаю, чего Вы хотите избежать, глубина соединения, больше, чем 7. 7 внутренних объединений меньше чем 7 соединений подробно, конечно, не неслыханны, но иногда люди слышат "7 соединений" и думают нет - нет 7 соединений, не глубина.