Одна из самых распространенных проблем при формировании отчетов - производительность. Конечно, нельзя исключать тот факт, что отчет имеет безумную подоплеку из бизнес-логики и обрабатывает огромное количество записей, прежде чем выдать результат. По своему опыту могу сказать, что есть множество случаев, когда используется SELECT SINGLE да и к тому же в цикле. БД в этом случае может чувствовать себя не очень хорошо, особенно, когда код написан совсем из рук вон плохо. Пока не прошла тенденция нагружать Application Server вместо сервера БД, есть отличная замена данного оператора. К серверу БД можно обратиться лишь раз и достать из него все необходимые данные. Чаще всего это не такое уж и большое количество записей, особенно если подумать и применить фильтр. После такой манипуляции можно смело заменить SELECT SINGLE на всем известный READ TABLE.
Но что если записей не так уж и мало? В этом случае READ TABLE будет сильно тормозить и мы не получим никакого ускорения. Но выход есть - хешированные таблицы. Доступ к данным - моментальный. Один нюанс - у них должен быть ключ. В нашем случае это не проблема, ведь вряд ли кто по своей воле использует SELECT SINGLE не по ключевым полям. Но если это все-таки случилось? Тогда нужно убрать дубликаты по ключам и все переложить в хеш-таблицу. Этот момент я мы и хотел отразить в виде кода.
Все, хеш-таблица заполнена, можно пользовать :)
Но что если записей не так уж и мало? В этом случае READ TABLE будет сильно тормозить и мы не получим никакого ускорения. Но выход есть - хешированные таблицы. Доступ к данным - моментальный. Один нюанс - у них должен быть ключ. В нашем случае это не проблема, ведь вряд ли кто по своей воле использует SELECT SINGLE не по ключевым полям. Но если это все-таки случилось? Тогда нужно убрать дубликаты по ключам и все переложить в хеш-таблицу. Этот момент я мы и хотел отразить в виде кода.
Все, хеш-таблица заполнена, можно пользовать :)
Комментарии
Отправить комментарий