Долгоиграющий запрос в Access

← →
msguns © (2004-11-04 17:32) [0]

Запрос:

DELETE FROM NT WHERE FID IN (SELECT DISTINCT NT.FID FROM NT,F WHERE NT.FID=F.TFID)

Детали:
База "местная"
В таблице NT 22тыс., в F 9,5тыс записей.
На поле FID индекса нет

Запрос выполнялся:
в SQL Exlorer > 15 мин.
в аксесе около 12 мин.

Если же этот подзапрос вложить в другой (вместо DELETE, например UPDATE) то время выполнения еще возрастает.

Это аксес такой или запрос или руки или мозги ? В IB такие штучки улетают незаметно. Неужели надо обязательно индексы ?

← →
Vlad © (2004-11-04 17:45) [1]

ну так для каждой удаляемой записи из NT строится подзапрос в 22тыс * 9.5тыс записей (поскольку индекса нет), а это многовато.
в IB возможно оптимизатор умнее (хотя я не проверял, только предполагаю) и строит таблицу всего один раз

← →
Johnmen © (2004-11-04 17:51) [2]

>Vlad © (04.11.04 17:45) [1]

Я тоже так думаю.
Вдуматься в логику запроса некому. А у ИБ, да и у любого SQL сервера есть кому. И этот кто-то поймет, что вложенный запрос достаточно выполнить 1 раз...

← →
msguns © (2004-11-04 17:55) [3]

Т.е. дело все же не в ручках (мозгах) ?
Если добавить индекс, насколько это повысит скорость ?

← →
sniknik © (2004-11-04 18:05) [4]

DELETE NT.*
FROM NT LEFT JOIN F ON NT.FID=F.TFID
WHERE NT.FID=F.TFID

по моему тоже самое удалит, но должен быстрее. а индексы желательны.

← →
Johnmen © (2004-11-04 18:05) [5]

>msguns © (04.11.04 17:55) [3]

Типа, пробуй. Потом расскажешь...
:)

← →
Prohodil Mimo © (2004-11-04 18:18) [6]

У меня было подобное, только не для удалений, а для выборок. Время открытия составляло более 20 минут. добавил индекс - менее секунды.

← →
MORA (2004-11-04 18:46) [7]

зачем спрашивать про индексы?
Создай и попробуй. Что это так долго или сложно?

← →
msguns © (2004-11-05 11:09) [8]

Повесил индексы. Результат:
в SQL Exlorer > 8 сек.
в аксесе 6 сек.

Мерзость в том, что прога лопатит базы, получаемые с периферии, и не содержащие индексов в нужных для репликации полях. Не я проектировал эту базу ("клоны" которой я получаю с "мест") и, соответственно, не мне делать какие-либо глобальные правки в бизнес-логике.
Выходит, что прога должна "на лету" создать нужные индексы и заюзать их при репликации. Результирующая база должны быть опять без этих индексов, т.к. отправляется в вышестоящую инстанцию в том же самом стандартном формате.

← →
Danilka © (2004-11-05 11:15) [9]

[8] msguns © (05.11.04 11:09)
А [4] пробовал?

← →
Johnmen © (2004-11-05 11:15) [10]

>msguns © (05.11.04 11:09) [8]

Создай индексы, выполни запрос, убей индексы.
Наверное, так будет быстрее, чем вообще без индексов.

← →
msguns © (2004-11-05 11:24) [11]

>Johnmen © (05.11.04 11:15) [10]

Убивать незачем. Я сделал специальную Базу, которую назвал БД Репликации. При старте репликации данные из "переиферийной" БД сначала закачиваются в буферные таблицы БДР (на которые я и повесил индексы), откуда интерполируются в специальные таблицы-раскладки, служащие для анализа и сопоставления "основной" и "вносимой" информации. Там она (инфа) просматривается и правится админом БД, после чего догружается в "основную БД", а она (База) уже, в свою очередь, уйдет "наверх". Т.е. периферийная БД не трогается, основная тоже.
В том, что индексы, конечно, помогут, и существенно, я не сомневался. Я интересовался тем, что неужели аксес такой тормозной ? Теперь мне понятно, почему разработчики некоторых прог (торговых, бухг), построенных на аксесе, настоятельно рекомендуют переходить на MS SQL (не забесплатно, ессно)

← →
sniknik © (2004-11-05 11:42) [12]

> Я интересовался тем, что неужели аксес такой тормозной ?
а меня всегда интересовало почему BMW так медленно ездит? правда у меня всегда на ручнике стоит и педаль тормоза в нажатом состоянии приварена... но это ж я так, для оригинальности сделал, вовсе не хотел чтобы медленно ездило...

← →
msguns © (2004-11-05 11:46) [13]

>sniknik © (05.11.04 11:42) [12]

;)))

Ну приколол, приколол.. ж)) А все же после IB на аксес как с мерса на запорожец. Сугубо ИМХО.

← →
sniknik © (2004-11-05 11:52) [14]

по аналогии, аксес это машина с ручной коробкой передач, а в руках дидетанта автомат имеет явные преимущества, а профи в нем очень редко встречаются. ;о))

мне наоборот в IB некоторых вещей аксеса не хватает. (когдато делал на IB связку так пришлось в одном месте для него процедуру писать, там где в аксесс легко можно в запросе все прописать) и не могу сказать что знаний нехватило (что правда, с IB не часто сталкивался) т.к. ту процедуру/ситуацию сдесь на форуме со многими обсуждали... другого выхода не нашли.

← →
Vlad © (2004-11-05 12:00) [15]

> а в руках дидетанта автомат имеет явные преимущества, а
> профи в нем очень редко встречаются. ;о))

Отставить дедовщину в форуме :о)

Да какая разница, Акцесс, Paradox или FoxPro к примеру, везде скорей всего эффект один и тот же будет, поскольку оптимизации запросов как таковой нету.

← →
sniknik © (2004-11-05 12:06) [16]

> поскольку оптимизации запросов как таковой нету.
ручками... пробуеш одно, другое, выбираеш подходящее.

автомат кстати, по контексту = автоматическая коробка передач. (а то вырваное чемто другим отдает)

>Vlad © (05.11.04 12:00) [15]
>Да какая разница, Акцесс, Paradox или FoxPro

Парадокс все же куда побыстрее будет (вместе с биде, конечно).
В аксесе чего стОит одна навигация по достаточно обширному курсору ;((

> msguns © (05.11.04 12:24) [17]

> В аксесе чего стОит одна навигация по достаточно обширному
> курсору ;((

Неужели медленно? А курсор какой, серверный или клиентский?

Ой чую грядет холивар Access vs IB ;-)

>Vlad © (05.11.04 12:37) [18]
>Неужели медленно? А курсор какой, серверный или клиентский?

Да, медленно (около 0,5 сек при переходе со строки на строку)
Замена в TADOConnect тиа курсора, моды и т.д. ни к чему не привела. Правда на событии AfterScroll сидит подкачка в 2 детала, но дочерних записей у каждого мастера единицы. Основная таблица большая в "длину" (более 70 полей) - может, это влияет ?
Да, и еще нет индексов (пока). Связь с "дочками" по прайм-ключам, ессно

> Да, и еще нет индексов (пока). Связь с "дочками" по прайм-ключам,
> ессно

На AfterScroll как я понимаю выполняется просто Close;Open детайлов?
Курсор у всех желательно установить серверный.

> Да, и еще нет индексов (пока). Связь с "дочками" по прайм-ключам,
> ессно

Т.е. в основной таблице есть PK, а в дочках FK нету?
Тогда понятно, почему тормоза. Причем по-моему для такого расклада скорость вполне нормальная.

>Vlad © (05.11.04 13:52) [20]
>На AfterScroll как я понимаю выполняется просто Close;Open детайлов?

Да, конечно.

>Курсор у всех желательно установить серверный.

Курсор коннекта серверный (был узерный, но это ничего не меняет)
Если поставить серверный у датасетов (TADOQuery), то тормоза усугубляются раза в полтора.

>Т.е. в основной таблице есть PK, а в дочках FK нету?

Связующее поле неключевое, но индексное.

>Тогда понятно, почему тормоза. Причем по-моему для такого расклада скорость вполне нормальная.

Т.е. я как бы не туплю ?

--------------------------------------------------------------------------------

> Причем по-моему для такого расклада скорость вполне нормальная.
и причем на парадоксе в таком же виде также с подтормаживанием работало бы.

> Т.е. я как бы не туплю ?
сделать быстрее наверняка можно (50/50).

> Связующее поле неключевое, но индексное.

т.е. в дочерних таблицах по полям связки индексы есть?
Тогда странно. Но дело явно не в 70-и полях, хотя.. нужно узнать для Access существуют ли какие-то ограничения на кол-во полей.
В IB есть ограничение на одну запись - 64К

Долгоиграющий запрос в Access Найти похожие ветки