Pull to refresh

Comments 5

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

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

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

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

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

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

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

Мне лень вникать в оригинал, но я почти на 100% уверен, что слово полнотекстовый тут ни при чем. Полнотекстовый обычно используется в другом смысле, а тут речь просто о full scan, который следует для маленьких таблиц кешировать — то есть, фактически, загружать их в память целиком.
Интересно, а почему возможность получить актуальный план выполнения описана только для PostgreSQL?
Для MSSQLSERVER, она, разумеется, тоже существует.
«обозначение big O» в русскоязычном матане имеет устойчивый термин «О большое». «в логарифмическом времени» — просто шикарно. Автор, Вам самому это слух не режет (если, конечно, русский язык для Вас родной)?
Sign up to leave a comment.

Articles