Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2008.04.06;
Скачать: [xml.tar.bz2];

Вниз

Запрос на обновление ужасно долго???   Найти похожие ветки 

 
DimDim ©   (2007-11-15 11:58) [0]

Уважакмые мастера, подскажите почему запрос вида
UPDATE Tab1 SET NumPole=Tab2.NumPole
FROM Tab1 INNER JOIN Tab2 (Tab1.Num = Tab2.Num)

выполняется 10 минут?!!!
В первой таблице 10 тыс. записей, во второй - 4 тыс.
Я че-то неправильно пишу?


 
Andrey ©   (2007-11-15 12:01) [1]

Индексы по tab1.num и tab2.num есть?
А используются?


 
Правильный_Вася   (2007-11-15 12:01) [2]

синтаксис довольно странный
через подзапрос не работает?


 
Anatoly Podgoretsky ©   (2007-11-15 12:07) [3]

> DimDim  (15.11.2007 11:58:00)  [0]

А что за такой странный синтаксис соединения, не стандартный.
Тогда чего же остального ожидать.


 
DimDim   (2007-11-15 12:15) [4]

Дык, подскажите не странный синтаксис.
Таблицы нигде не используются. Являются промежуточными для формирования следующего запроса.


 
Anatoly Podgoretsky ©   (2007-11-15 12:25) [5]

А зачем тебе не странный синтаксис, если он твоему движку не подойдет.
Если интересно, то можешь сам посмотреть или в LocalSQL, или в JETSQL


 
DimDim   (2007-11-15 13:30) [6]

Синтаксис запроса соответствует документации на движки:

Syntax

UPDATE table_reference
[AS correlation_name | correlation_name] [EXCLUSIVE]

SET column_ref = update_value
[, column_ref = update_value...]

[FROM table_reference
[AS correlation_name | correlation_name] [EXCLUSIVE]

[[INNER | [LEFT | RIGHT] OUTER JOIN] table_reference
[AS correlation_name | correlation_name] [EXCLUSIVE] ON join_condition]

[WHERE predicates]

[COMMIT [INTERVAL commit_interval] [FLUSH]]


Ошибок никаких не дает. Но почему так медленно?????


 
Reindeer Moss Eater ©   (2007-11-15 13:35) [7]

Потому что фулскан


 
Johnmen ©   (2007-11-15 13:42) [8]


> Ошибок никаких не дает.

Либо это враньё, либо [0] враньё. В "соответствии документации на движки".


 
Andrey ©   (2007-11-15 13:45) [9]

Так всётаки
>Индексы по tab1.num и tab2.num есть?
>А используются?

Синтаксис странный, но я слыхал про СУБД с возможностью update from select. Если у автора не ругаеццо движок, а даже что-то обновляет, то значит в "DBISAM" такой работает (вообще первый раз слышу про СУБД "DBISAM" ))


 
Anatoly Podgoretsky ©   (2007-11-15 14:08) [10]


> Ошибок никаких не дает. Но почему так медленно?????

Врешь, приведеный запрос не соответствует спецификации.


 
DimDim   (2007-11-15 14:09) [11]

Всем спасибо.
Сделал через временную таблицу - выборку из tab2 с индексацией по Num. И в запросе на обновление подвязал уже эту временную таблицу. Время выполнения сократилось до 2 сек.

P.S.
А DBISAM - мне нравится. Работаю с ней 4 года. По сути полностью аналогична парадоксу и dBase, но при этом гораздо стабильней. Если даже что-то полетело, то есть внутреняя функция восстановления таблиц (Rapair), которую можно запускать из самой программы. Не требует никаких внешних драйверов. Все компилируется в программу.


 
Johnmen ©   (2007-11-15 14:11) [12]


> DimDim   (15.11.07 14:09) [11]

Да вы прирожденный проктолог!


 
Johnmen ©   (2007-11-15 14:13) [13]

Но можете перечитать [7], [8], [10] и подумать.


 
Andrey ©   (2007-11-15 14:18) [14]

>DimDim
И всётаки он скорее всего индекс у тебя не пользовал... а теперь стал... или еще почему хз.

>Anatoly Podgoretsky ©   (15.11.07 14:08) [10]
>Врешь
А ведь и не врет. Запрос соответсвует спецификации. Спецификации которую он привел ) Ведь далеко не все РСУБД строго соблюдают SQL89/92/98/2003... Видать и эта решила отличиться )
Между прочим, судя из способа использования, в очень даже лучшую сторону. Мне было бы приятно иметь возможность на том же FB подобные конструкции писать.


 
sniknik ©   (2007-11-15 14:34) [15]

> А ведь и не врет.
врет. посмотри внимательнее на условие объединения в запросе и приведенной справке.

> Мне было бы приятно иметь возможность на том же FB подобные конструкции писать.
а разве там нет подобного? (в MSSQL есть, по спецификации, не по запросу в [0], и насколько знаю, в FB многое из MSSQL взято...)


 
Anatoly Podgoretsky ©   (2007-11-15 14:35) [16]

> Andrey  (15.11.2007 14:18:14)  [14]

Врет, ты внимательно посмотри на спецификацию и текст его запроса.
Сомневают, что его конструкция как то пойдет на FB
Ну не допускают таких волностей интерпритаторы SQL выражений.
Я даже уверен, что он привел не тот запрос, который не работает, а тот который ближе лежал, может даже из головы.


 
Andrey ©   (2007-11-15 14:46) [17]

>Anatoly Podgoretsky ©   (15.11.07 14:35) [16]
Ну судя по именм таблиц/полей - и правду из голвы. Этим я себе могу объяснить, что он пропустил обязательное слово ON в предложении join. Вобщем это простительная ошибка, как на мой взгляд.
Плюс ко всему в строке из спецификации:
[[INNER | [LEFT | RIGHT] OUTER JOIN] table_reference
чисто интуитивно понятно, что перед словом OUTER должен быть "|". Т.к. inner join это не outer join.

А в остальном, прошу разъяснить как для паровоза, где его запрос не соответсвует приведенной им спецификации.

>sniknik
Ну это еще кем что у кого взято надо посмотреть )
помню как на sql.ru в форуме по FB радовались, что MS планирует вариант с применением версионной архитектурой.
Но update from select я у FB не видел... Может опять плохо смотрел.


 
Johnmen ©   (2007-11-15 14:47) [18]

А я намекал, как и RME, в последнем посте на то, что вот такая ошибка в написании запроса может привести к неожиданным последствиям. Но вполне понятным. И запрос выполнится, и долго будет :)


 
sniknik ©   (2007-11-15 14:57) [19]

> Ну это еще кем что у кого взято надо посмотреть )
это без разницы, просто для меня mssql первоисточник т.к. с ним работаю, а FB вторично т.к. только изредка чегонибудь проверишь да и все.

> Но update from select я у FB не видел...
селекта в запросе нет... и в спецификации тоже. смотри внимательнее.


 
sniknik ©   (2007-11-15 14:58) [20]

запрос и спецификация приведенные имеются ввиду конечно же.


 
Andrey ©   (2007-11-15 15:07) [21]

>sniknik ©   (15.11.07 14:57) [19]
>селекта в запросе нет... и в спецификации тоже. смотри внимательнее.
Да, убедил, там нет селекта. Там есть возможность задать несколько источников данных в предложении from, использовать данные этих источников для фильтрации и обновления данных обновляемого источника. А вот селекта нет. Ты прав.
Там только часть функционала селекта. Часть логически обоснованная контекстом использования.


 
sniknik ©   (2007-11-15 15:25) [22]

> Там только часть функционала селекта.
селект не имеет монополии на класс from, т.что это не часть только функционала селекта.

из справки (mssql естественно)
FROM
Specifies the tables, views, derived tables, and joined tables used in DELETE, SELECT, and UPDATE statements.


 
Andrey ©   (2007-11-15 15:44) [23]

>sniknik ©   (15.11.07 15:25) [22]
>селект не имеет монополии на класс from
) мне всегда трудно давалось общение с pure перфекционистами... хотя я и сам, но не слишком pure.
Ну да, нужно было написать не "update from select", а просто "update from". С формальной точки зрения это было бы правильнее )


 
Anatoly Podgoretsky ©   (2007-11-15 15:46) [24]

> Andrey  (15.11.2007 14:46:17)  [17]

Непростительная, нафига нам обсуждать какой то посторонний запрос. Искать ключ там где светлее, а не там где уронил.


 
Andrey ©   (2007-11-15 15:54) [25]

>Anatoly Podgoretsky ©   (15.11.07 15:46) [24]
Для меня простительная. Т.к. когда сам спрашиваю, иногда привожу не оригинальный код, а адаптированый и урезаный вариант (другое дело, что я в инете уже года 4 ничего не спрашиваю, спасибо мастакам, отбили желание). Ну не кидать же автогенерируемую портянку на 1,5 экрана в которой сам глаза сломал 2 раза.


 
Anatoly Podgoretsky ©   (2007-11-15 16:46) [26]

> Andrey  (15.11.2007 15:54:25)  [25]

Не надо, но надо до того как бросать убедиться, что она

раз. рабочая
два. позволяет воспроизвести проблему

Разве была бы претензия, если бы был правильный код?


 
Andrey ©   (2007-11-15 17:06) [27]

Если бы код был правильный - не было бы вопроса вообще )
Кстати, автор не высказался на тему "будет ли работать первоначальный запрос если после join добавить on". Если будет работать, значит запрос приведенный "рабочий" и "позволяет воспроизвести ошибку" и всё дело было в отсутствии "on".

Ладно, по сути это всё уже не важно, автор нашел альтернативное решение, а мы переливаем из пустого в порожнее )


 
DimDim   (2007-11-15 20:43) [28]

ON действительно пропустил в примере. Каюсь.
А весь реальный код писать смысла нет - много лишней ненужной информации и тяжелей читается. Но раз хотите реальный код - пожалуйста:
 if Q1.Active=True then Q1.Close;
 Q1.DatabaseName:=KatalogTemp;
 Q1.SQL.Clear;
 Q1.SQL.Add("UPDATE Rab_mat SET ");
 Q1.SQL.Add("  Kol_K = ROUND(Rab_mat.Kol*R_RepTmp.K_MAT*R_RepTmp.VR,4)");
 Q1.SQL.Add("FROM Rab_mat INNER JOIN R_RepTmp");
 Q1.SQL.Add("  ON (Rab_mat.Auto = R_RepTmp.Auto)");
 try
   Q1.ExecSQL;
   except
   Application.MessageBox(PAnsiChar("Ошибка пересчета ресурсов !"),
      "Ой !",MB_ICONSTOP);
   end;  



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2008.04.06;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.52 MB
Время: 0.007 c
2-1204861213
Георгий
2008-03-07 06:40
2008.04.06
FormActivate


2-1205411574
Podarok
2008-03-13 15:32
2008.04.06
Помогите найти функцию, не знаю как точно называется


2-1205260654
Chainic
2008-03-11 21:37
2008.04.06
Паскаль


2-1205398187
Julia
2008-03-13 11:49
2008.04.06
CreateDBF


2-1204701121
kudatsky
2008-03-05 10:12
2008.04.06
Под User не читается Registry





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский