Так уж сложилось что MSSQL не имеет своего аналога функции LIMIT в MySQL (за исключением TOP). Но достаточно часто возникает необходимость выбрать определенный интервал значений не с первого а например с 1000-го.

Мой друг написал в песочнице статью, которая оказалась для меня (и не только) полезной, но через 7 дней была удалена. С его разрешения привожу её ниже. Если кому она тоже будет полезной, то он просит выслать ему инвайт на alxsad@gmail.com .

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

$pages = new Model_Pages();
$paginator = Zend_Paginator::factory($pages->getRows());
$paginator->setItemCountPerPage(1);
$paginator->setPageRange(1);
$paginator->setCurrentPageNumber($this->getRequest()->getParam('page', 1));
Zend_Paginator::setDefaultScrollingStyle('Sliding');
$this->view->pages = $paginator;
$paginator->setView($this->view);
Zend_View_Helper_PaginationControl::setDefaultViewPartial('paginator.phtml');
$this->view->paginator = $paginator;

* This source code was highlighted with Source Code Highlighter.

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



Видите? Проблема заключается в том, что люди сразу забирают ВСЕ записи из базы данных, а потом уже из них выбирают нужные. Это огромная ошибка. Поэтому читаем как это делается
правильно.

Как человек, занимающийся терминальными службами Microsoft, Citrix и другими, часто сталкиваюсь у заказчиков с ситуацией, когда на сервер ставится 8, 16 и более гигабайт памяти для работы с 32 разрядной операционной системой. Теоретические знания и практические наблюдения позволяют настаивать на том, что для 32-разрядной операционной системы больше 4 гигабайт памяти ставить расточительно и неверно. Не только из-за того что операционная система не использует всю память (без PAE), а из-за того, что 32-bit приложение не умеют, в большинстве своем, с таким объемом памяти работать.

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Предыстория

Не так давно, в связи с производственной необходимостью, я познакомился с замечательным фреймворком Symfony 2, в котором для работы с базой данных используется мощная популярная библиотека — Doctrine 2, включающая в себя два компонента: ORM (Object relational mapper) и DBAL (Database Abstraction Layer). ORM предоставляет приложению возможность общаться с базой данных на языке объектов, а DBAL, в свою очередь, представляет собой более низкоуровневый способ доступа к данным посредством написания запросов, основанный на php-библиотеке PDO. ORM предоставляет множество преимуществ при разработке сложных бизнес-приложений, но в то же время налагает и ряд ограничений, связанных с тем, что разработчику не приходится писать непосредственно SQL-запросы — ORM Doctrine предлагает свой собственный, объектно-ориентированный язык запросов, который преобразуется в привычный SQL уже за кадром. С одним из таких ограничений я и столкнулся, и хочу поделиться, каким образом я его успешно преодолел. Речь пойдёт о получении общего количества записей, возвращаемых запросом, если убрать из него ограничение LIMIT.

До недавних пор я создавал сайты и плагины на WordPress, арендуя виртуальные хостинги у провайдеров. Для себя еще давно выделил панель ISP за удобность и практичность. Так случилось, что все время работал на Windows, следовательно, Linux для меня — темный лес с диким животными. Сайты со временем «росли» и становились более требовательны, как минимум к дисковому пространству и иногда к оперативной памяти.

Пару месяцев назад по некоторым соображениям решил арендовать виртуальный сервер на Linux и самостоятельно установить туда ISP и BILL для создания и управления услугами.

Поколдовав несколько часов с документацией и SSH консолью, я запустил свой первый сервер на CentOS. В течение недели выяснил: почему gmail.ru и mail.ru не хотят принимать письма с моего хостинга, как устанавливать ограничения на дисковое пространство, контролировать настройки php для каждого виртуального хостинга и что BILL, имея в своем арсенале возможность покупки дополнительных параметров, включая пункт «Оперативная память», не может на самом деле устанавливать ее.

Лимит

Есть на LinkedIn такое ограничение — Лимит коммерческого использования. Крайне вероятно, что вы, как и я до недавнего времени, никогда не сталкивались и не слышали о нем.



Суть лимита в том, что если вы используете поиск людей вне ваших контактов слишком часто (точных метрик нет, решает алгоритм, на основе ваших действий — как часто и много искали, добавляли людей), то результат поиска будет ограничен тремя профилями, вместо 1000 (по умолчанию 100 страниц, по 10 профилей на страницу). Лимит сбрасывается в начале каждого месяца. Естественно, премиум аккаунты такого ограничения не имеют.

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

[Because my extension got a lot of attention from the foreign audience, I translated my original article into English].

Limit

Being a top-rated professional network, LinkedIn, unfortunately, for free accounts, has such a limitation as Commercial Use Limit (CUL). Most likely, you, same as me until recently, have never encountered and never heard about this thing.



The point of the CUL is that when you search people outside your connections/network too often, your search results will be limited with only 3 profiles showing instead of 1000 (100 pages with 10 profiles per page by default). How ‘often’ is measured nobody knows, there are no precise metrics; the algorithm decides it based on your actions – how frequently you’ve been searching and how many connections you’ve been adding. The free CUL resets at midnight PST on the 1st of each calendar month, and you get your 1000 search results again, for who knows how long. Of course, Premium accounts have no such limit in place.

However, not so long ago, I’ve started messing around with LinkedIn search for some pet-project, and suddenly got stuck with this CUL. Obviously, I didn’t like it that much; after all, I haven’t been using the search for any commercial purposes. So, my first thought was to explore this limit and try to bypass it.

[Important clarification — all source materials in this article are presented solely for informational and educational purposes. The author doesn't encourage their use for commercial purposes.]

Этот пост родился как расширенный ответ на умозрительную задачу, обозначенную в статье «Хроники пэйджинга».

Пусть у нас есть реестр документов, с которым работают операторы или бухгалтеры в СБИС, вроде такого:



Традиционно, при подобном отображении используется или прямая (новые снизу) или обратная (новые сверху) сортировка по дате и порядковому идентификатору, назначаемому при создании документа — ORDER BY dt, id или ORDER BY dt DESC, id DESC.

Типичные возникающие при этом проблемы я уже рассматривал в статье «PostgreSQL Antipatterns: навигация по реестру». Но что если пользователю зачем-то захотелось «нетипичного» — например, отсортировать одно поле «так», а другое «этак» — ORDER BY dt, id DESC? Но второй индекс мы создавать не хотим — ведь это замедление вставки и лишний объем в базе.

Можно ли решить эту задачу, эффективно используя только индекс (dt, id)?

В этой серии статей мы подробно рассмотрим, почему и как недавно были внесены изменения в наши Условия обслуживания. Эта статья подробно опишет политику хранения неактивных образов, а также то, как она повлияет на команды разработчиков, использующих Docker Hub для управления образов контейнеров. Во второй части мы сосредоточимся на новой политике по ограничению частоты скачивания образов.

Это вторая статья из серии статей, в ней будут рассмотрены ограничения при скачивании образов контейнеров.