su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Vladimir Pavlikov                    2:5020/400     16 Apr 2003  16:59:00
 To : Nik Sestrin
 Subject : Re: БД в тopгoвлe
 -------------------------------------------------------------------------------- 
 

 Hello, Nik Sestrin!
 You wrote to Vladimir Pavlikov on Wed, 16 Apr 2003 02:57:39 +0000 (UTC):
 
  NS>>> 1. msaccess со своей фильтрацией - аргумент?
 
  >> фильтрующие механизмы нужны файл-серверной
  >> апликухе! И даже если она используется, как клиент полноценного
  >> сервера, сам инструмент при этом никак не меняется...
 
  NS> вот именно, не меняется! хотя при работе акцесса клиентом серверной
  NS> СУБД меняется куча всего. разработчики оставили это, так как оно
  NS> вполне применимо и для сервера.
 
 Ты сам понял, что сказал? Инструментальный пакет ms access - это
 монолит в поставке. Он не меняется волшебным образом при разном
 его использовании просто потому, что не может... И - см. ниже.
 
  NS> я не думаю, что разработчики АДО настолько глупы, чтобы не применить
  NS> возможности быстрого поиска и в клиентском рекордсете, раз
 
 1. АДО, так же, как и акцесс - средство работы с _разными_ типами
 движков. Hе нужно продолжать перечисление подобного (оно довольно
 длинное) - это один и тот же "аргумент".
 2. "Аргументы" уровня "разработчики чего-то сделали - значит умно"
 прибереги для других, ибо :
 - глупостей в софте (от ms в частности) немерено
 - разработчики часто делают что-то не потому, что считают умным,
   а потому, что это пользуется спросом у "умных" юзеров.
 
  NS> тот же like не отъиндексируешь, а он очень интересен юзерам, когда
  NS> они что-то ищут, нетвердо помня что, два
 
 Как влияют индексы? Записи в любом случае нужно первоначально
 отобрать на сервере. Считаешь, "отдать все" и затем отфильтровать
 на клиенте будет быстрее? Это вряд-ли...
 
  NS> обрати также внимание, что в моем случае данные как правило лежат в
  NS> _памяти_, а не на _диске_ сервера (конечно они могут быть и в памяти
  NS> сервера, но кэш может быть уже очищен, т.к. между первоначальным
  NS> запросом и дофильтрацией время совершенно неопределенное -
  NS> человеческий фактор)
 
 Данные лежат на диске сервера. Точка. А в память их поднимает именно
 сервер - я не вижу отношения к теме.
 
  NS> еще: на все ли необходимое для поиска ты имеешь индексы в
  NS> ОЛТП-системе?
 
 Хочу попросить тебя все же как-то обозначать отношение говоримого
 к рассматриваемому вопросу - я не умею реагировать "на поток соз-
 нания".
 
  >> Я не заказывал.
 
  NS> просил другой человек, не хотелось одно и тоже постить 2 раза
 
 Зачем два? Достаточно одного, по адресу - не было бы недоуменных
 вопросов от обоих.
 
  NS> и мы сидим с этими компонентами (куда от них денешься в любом
  NS> случае?), но чтобы соблюсти идею фильтрации на сервере, проигрываем
  NS> в скорости в десяток раз?
 
 Это суметь надо - я, как правило, выигрываю. И никогда не проигрываю.
 
  NS> я не против, если кто-то повторит опыт с другим сервером. однако же
  NS> считать mssql настолько тупым как-то малоубедительно
 
 Дело не в тупости сервера, а в непонятности (для части присутствующих)
 самого скрипта. Как можно делать выводы из непонятого?
 
  >> (я не понял, сколько их в таблице) передача 10000 записей
 
  NS> и меня же обвиняют в невнимательном чтении конфы:
 
 Почему сразу обвиняют? - констатируют факт :)
 
  NS> т.е. 9*(2^13)=73728
 
 Около 16%... Возможно, скан тут действительно дешевле.
 
  >> ЗЫ. Ты не мог бы отвечать все же по месту, и удалять ненужный текст?
 
  NS> в целом твой постинг означал "так где же твои аргументы?", смысла
  NS> отвечать на каждую фразу я не увидел
 
 Вот сейчас удалил (за что спасибо) - и не пришлось перечитывать
 свою писанину, чтобы убедится в отсутствии на нее реакций :)
 
  NS> итак, меряем :
  NS> r.open "select * from ft where id<10000 and name like '%21%'", c ',
  NS> 3, 3 и
  NS> r.filter="name like '%21%'"
  NS> результат (его порядок несколько другой - компьютер тут
  NS> тормознутый):
  NS> Фильтр на сервере: 4,29 сек
  NS> Фильтр на клиенте: 0,01 сек
  NS> катастрофически!
 
 Угу. Попробуй поменять запрос и фильтр местами, т.е. переверни
 последовательность. Очень похоже, что фильтр пользуется кешем,
 обеспеченным запросом.
 ---------------------------------------------
           Владимир Павликов.
 -- 
 Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
 --- ifmail v.2.15dev4
  * Origin: Talk.Mail.Ru (2:5020/400)
 
 

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