Руководство по SQL: Как лучше писать запросы (Часть 2)

[sshikov]

Для запросов это означает, что они будут выполняться, если время выполнения пропорционально логарифму размера базы данных.

Что-то?

[GlukKazan]

Да в этой статье все предложения такие. Первое же предложение убивает напрочь своей согласованностью членов. SQL читать проще чем русскоязычный текст в этой статье.

[sshikov]

Чистая правда…

Вообще, нормальный с точки зрения полезности текст (если оставить за кадром вопросы, возникшие еще к первой части, и считать, что он для продвинутых, и посвящен оптимизации). Но на этот раз — ужасно не вычитанный. Один пример уже привел выше. Вот еще один:

Вы считаете, что у вас оптимальный дизайн для запроса, но не пытайтесь проверить свои предположения.

Тут слова в предложении не согласованы. Смысл постичь удается, но приходится напрячься.

Или вот:

Минимальная сложность может быть O(n log(n)), но максимальная сложность может быть O(n^2), основанная на информации индекса атрибутов соединения.

Снова несогласованность, и что важнее — это скорее следовало бы записать как «на основании индексов по атрибутам», т.е. сложность никак не «основанная на», а «в зависимости от» — она зависит от наличия и вида индексов, и далее в таком же духе.

кэширование полнотекстовых сканирований малых таблиц

Мне лень вникать в оригинал, но я почти на 100% уверен, что слово полнотекстовый тут ни при чем. Полнотекстовый обычно используется в другом смысле, а тут речь просто о full scan, который следует для маленьких таблиц кешировать — то есть, фактически, загружать их в память целиком.

[uaggster]

Интересно, а почему возможность получить актуальный план выполнения описана только для PostgreSQL?
Для MSSQLSERVER, она, разумеется, тоже существует.

[vadim_bv]

«обозначение big O» в русскоязычном матане имеет устойчивый термин «О большое». «в логарифмическом времени» — просто шикарно. Автор, Вам самому это слух не режет (если, конечно, русский язык для Вас родной)?