 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : ЏгвЁ«Ё …ўЈҐЁ© ‚ «ҐвЁ®ўЁз 2:5020/400 28 Feb 2003 18:16:52 To : Dmitry Kuzmenko Subject : Re: постреляционные базы данных -------------------------------------------------------------------------------- DK>> таким образом, все (!) данные в SQL-таблице - сугубо вычисляемые. DK>> Какова будет реальная производительность если все делать только в SQL - DK>> я затрудняюсь ответить (мне даже представить страшно). Короче, после DK>> некоторого ковыряния с SQL разработчик прямиком отправится на нижний DK>> уровень (к глобалям) и дальше застрянет там. Hу это немного емперические выводы. Сразнивал один и тотже запрос на одинаковых БД, созданных по CREATE TABLE. FB 1.0 и Cache. Hикакими локальными возможностями Cache не пользовался. Запрос на SQL большой select e.ID_P,a.ID_DOC,sum (a.COUNT_F) from GOODINORDER a,RELCON2CONWTRE b,RELTRE2TREWTRE c, RELDOC2TREWTRE d,RELCON2DOCWTRE e, DOCUMENT f, DOCUMENT g where b.ID_P = :id_contactor and b.ID_OLD_P = 0 and b.ID_TREE = :ID_TREE_rc and b.ID_OLD_TREE = 0 and c.ID_TREE = :id_tree and c.ID_OLD_TREE = 0 and d.ID_TREE = 86 and d.ID_OLD_TREE = 0 and d.ID_S=c.ID_P and d.ID_OLD_S=c.ID_OLD_P and e.ID_TREE=c.ID_S and e.ID_OLD_TREE=c.ID_OLD_S and d.ID_P=e.ID_S and d.ID_OLD_P=e.ID_OLD_S and b.ID_S=e.ID_P and b.ID_OLD_S=e.ID_OLD_P and e.ID_S=f.ID and e.ID_OLD_S=f.HOWOLD and a.ID_DOC=f.ID and a.ID_OLD_DOC=f.HOWOLD and (f.PRINTDATE <= :PRINDATE) and (a.ID_TREE = :id_type) and (a.ID_GOOD = :id_good) and (b.ID_OLD_P = 0) and (b.ID_OLD_S = 0) and (b.ID_OLD_TREE = 0) and (c.ID_OLD_P = 0) and (c.ID_OLD_S = 0) and (c.ID_OLD_TREE = 0) and (d.ID_OLD_P = 0) and (d.ID_OLD_S = 0) and (d.ID_OLD_TREE = 0) and (e.ID_OLD_P = 0) and (e.ID_OLD_S = 0) and (e.ID_OLD_TREE = 0) and (a.ID_ACTION between 0 and 20000000) and a.id_action=g.id_action and g.howold=0 group by e.ID_P,a.ID_OLD_DOC,a.ID_DOC,a.ID_OLD_DOC,a.ID_GOOD, a.ID_TREE having ( sum (a.COUNT_F) > 0) Cache сделал IB по производительности раз в 20. К сожалению нагрузку на несколько одновременно выплняемых запросах и при изменении данных не тестировал. Когда был в представилесве в Мсокве, там скаазали что есть клиенты которые мигрировалили с IB на Cache именно изза скорости. С уважением Путилин Евгений Валентинович --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/16679023f69c0.html, оценка из 5, голосов 10
|
|
|