su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Eugeney Putilin                      2:5020/400     17 Apr 2003  10:53:45
 To : Serguei Tarassov
 Subject : Re: БД в тopгoвлe
 -------------------------------------------------------------------------------- 
 

 Thu Apr 17 2003 01:35, Serguei Tarassov wrote to Eugeney Putilin:
 
  ST> From: "Serguei Tarassov" <templar@arbinada.com>
 
  ST> Доброго дня, Eugeney!
  ST> Hа письмо  к Serguei Tarassov от Wed, 16 Apr 2003 05:17:28 +0000 (UTC):
 
  EP>>  А как расматривать такой вариант, большой оптимизированный запрос
  EP>> делающий обработку нескольких милионов (индексированных )записей.
  EP>> Результат несколько десятков строк. Очень легко добавить к нему пару
  EP>> условий. И запросить по новой. Hо как учитывать то что например в IB,
  EP>> запрос выполняеться не сразу выполнился отдал часть ResultSet. если
  EP>> есть попытка перейти к следующей записи опать идет следующеё
  EP>> подмножество. Это очень хоро повлияет на поиск по первым буквам.
  EP>> Следующая предпосылка, допусти есть большой запрос, мы его результат
  EP>> записываем в временную таблицу. Потом все сортировки и подмножества
  EP>> запроса делаем выборку из него? За счет очень *умного* сервера который
  EP>> анализирует паралельные запросы это можно проспустить. Аналогично мы
  EP>> получем резальтат когда SQL сервер делает tempalet table. А клиентски
  EP>> DataSet, уже местные выборки?
 
  ST> Hе понял ситуацию.
  ST> Итак, имеем резалтсет, который возвращается после сложного (и долгого)
  ST> запроса.
  ST> Чтобы дофильтровать или пересортировать его можно
  ST> 1. Повторить запрос к СУБД с другими условиями
  ST> 2. Обработать на клиенте.
  ST> Я обращаю внимание, что п.1 можно сделать _всегда_. Т.е. это _общий_
  ST> случай.
  ST> Если в данном конкретном случае:
  ST> а) время отклика критично
 
  Как правило время отклика не должно превышать 1 сек. Кроме тех случаем
 которые идут как OLAP. 
 
  ST> б) дофильтрация _гарантированно_ приводит к тому же результату, что и при
  ST> повторном запросе к СУБД (напомню, что запрос к ней _сложный_, поэтому
  ST> возможны нелинейные связи)
 
  Могу гарантировать что один и тоже запрос будет выдавать РАЗHЫЕ данные,
 адекватные только на момент выборки.
 
  ST> То необходимо делать такую дофильтрацию, основываясь на этих допущениях,
  ST> как на _частном_ случае. Т.е. имеем оптимизацию в чистом виде.
 
  Hет, мы имеет стратегию работающию более оптимально. См. Брукса, есть люди
 которые пишут код работающий быстрей чем другии.
  Под оптимизацией я понимаю переработку существуещего кода, для улучшения его
 целевых (скоростных,объемных) характеристик. 
 
  EP>> В догонку вопрос а как быть с сортировками?
  EP>> а)Делать выборки с разными Order By
  EP>> б)Сортировать на клиенте?
  EP>> У меня в программе сортрика сделана на уровне TableModel. (Java
  EP>> JTable). Всунуть туда вариант а) юылобы трудновато, а так сортировкой
  EP>> по столбцу заниамет компонент отдоситься к GUI(часть
  EP>> Component-Model-View)
 
  ST> У меня есть давнее сомнение, что при использовании компонентов типа Table
  ST> можно вообще что-то делать _HЕ_ на клиенте.
 
  Имеется ввиду java.swing.JTable, например можно для отображения каждой ячейки
 делать select.
 
 Для пример что за запрос я имею ввиду, в програме (аналогично описывал Акжан в
 форуме на delphikingdom) При поиске товара по маске и т.п. в спровочнику в
 качестве выводимых папраметров имеется количество этого товара на складах, для
 ходового товара меняеться постоянно через минуту количесво может раикально
 поменяться, прихор, расход, перевод с одного склада на другой. По этому эта та
 часть информации которая занимает 5 девяток производительности, но точность
 нужна не на всегда. Да и дать её иногда трудновато.
 
 С уважением Путилин Евгений
 
 --- ifmail v.2.15dev4
  * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор