Вопрос о SQL из статьи Joel Spolsky
MapTiler Desktop использовался для рендеринга, например, Disqus Universe . Это то, что вы ищете?
3 ответа
Очевидно, = b и b = c => = c - это связано с переходным закрытием. Мнение, которое высказывал Joel, - то, что некоторые SQL-серверы плохи при оптимизации запросов, таким образом, некоторые SQL-запросы могли бы быть записаны с "дополнительными" спецификаторами как в примере.
В этом примере помните, что a, b и c как выше часто относятся к различным таблицам, и операции как a=b выполняются как соединения. Предположим, что количество записей в таблице a 1000, b 500, и c равняется 20. Затем соединение a, b потребности 1000x500 сравнения строки (это - мой немой пример; на практике могли бы быть намного лучшие алгоритмы соединения, которые уменьшат сложность много), и b, c потребности 500x20 сравнения. Оптимизирующий компилятор решит, что соединение b, c должно быть выполнено сначала, и затем к результату нужно присоединиться на = b, так как существует меньше ожидаемых строк с b=c. Всего существуют о 500x20 + 500x1000 сравнения для (b=c) и (a=b) соответственно. После этого пересечения должны быть вычислены между возвращенными строками (я предполагаю также через соединения, но не уверенный).
Предположим, что SQL-сервер мог иметь логический модуль вывода, который также выведет, что это означает = c. Затем это, вероятно, выполнило бы соединение b, c и затем соединение a, c (снова, это - гипотетический случай). Это взяло бы 500x20 + 1000x20 сравнения и после того пересечения вычисления. Если ожидается # (a=c) меньше (из-за некоторых знаний проблемной области) затем, второй запрос будет намного быстрее.
В целом мой ответ стал слишком длинным, но это означает, что оптимизация SQL-запроса не является тривиальной задачей, и именно поэтому некоторые SQL-серверы не могут сделать этого очень хорошо.
Больше может быть найдено по http://en.wikipedia.org/wiki/Query_optimizer, или от некоторых ожидают на базах данных, читая это.
Но философски говоря, SQL (как абстракция) был предназначен для сокрытия всех аспектов реализации. Это было предназначено для описания (SQL-сервер может самостоятельно использовать методы оптимизации запроса SQL для перефразирования запроса для создания их более эффективными). Но в реальном мире это не так - часто, запросы базы данных должны быть переписаны людьми для создания их более эффективными.
В целом, точка статьи - то, что абстракция может только быть настолько хорошей, и никакая абстракция не прекрасна.
Вот более простое объяснение, где все - все в одной таблице.
Предположим A и C оба индексируются, но B не. Если оптимизатор не может понять, что = C, то он должен использовать неиндексируемый B для обоих ГДЕ условия.
Но если Вы затем говорите серверу, что a=c, он может эффективно применить тот фильтр сначала и значительно уменьшить размер рабочего набора.
Я думаю, что "определенное" слово является действующим термином здесь. Для оптимизатора, чтобы действительно понять, что a=c, это должно было бы проанализировать и затем соединить равенство a весь путь к "c" в переходных отношениях для выведения отношений.
Я думаю, что в будущем, оптимизаторы SQL могли бы получить это умное (если они уже не), таким образом, IMO это не действительно общее утверждение относительно части Joel.