|
|
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
есть у меня цепочка сохранённых запросов... Вопрос в следующем. При вызове конечного запроса в котором может несколько раз использоваться "подчинёные" запросы, "подчинёные" запросы - будут пересчитываться при каждом их обнаружении или толко раз? Каждый "подчинёный" запрос во всех случаях выдаёт один и тот же результат. Access'97 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 10:21 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
У меня уже возникал такой вопрос. В результате перелопачивания больших объемов информации с иностранных сайтов выяснил, что подчиненные запросы в Microsoft Access до 97 версии включительно вызываются каждый раз заново. Microsoft клятвенно обещал, что этот недочет будет исправлен в следующих версиях (по информации из тех же источников). Появилась эта возможность в новых версиях (2000, XP) или нет - я так и не смог выяснить (нет и инете или просто не нашел). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 10:48 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Для того чтобы избежать повторного выполнения подзапросов процессор запросов должен обладать недюжим "интеллектом". От MSJET этого ждать не приходится ни сейчас, ни в будущем, тем более что существует его приемственник - MSDE. А это уже полноценный SQL сервер, с очень мощным оптимизатором запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 10:52 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Спасибо за разочерование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 11:58 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Ну что уж сразу и разочарование? Методы борьбы есть. К примеру результат промежуточного запроса можно выкинуть в табличку, а в основных запросах ее использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 12:18 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
так то оно так... но тогда на кажное обновление надо её переписывать... хотя... что то в этом есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 12:34 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Что-то у меня сомнения в том, что в 97-м оно всегда пересчитывается. Например, аксесу хватает интелекта чтобы функции не вызывать кждый раз - если оно не надо (иногда оно и мешает). Если не рассматривать коррелированные запросы (должны всегда перевыполняться), то почему бы аксесу не выполнить подчиненный запрос один раз? Попробую проверить, если что - напишу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 12:57 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Похоже мои сомнения были оправданы Имеем две таблицы Таблица1 и Таблица2 с полем А. Данные - от целые числа 1 до 5. Пишем функцию Код: plaintext 1. 2. 3. Пишем Запрос1 Код: plaintext 1. После выполнения в дебуге цифры 1-5 Пишем Запрос2 Код: plaintext 1. В дебуге - одна цифра. Т.е. запрос исполнился адын раз. Чего и следовало ожидать. Ну а если Запрос3 Код: plaintext 1. то в дебуге опять пять цифр, т.е. вложенный запрос исполнился для каждой строки, чего тоже следовало ожидать. P.S. 2 Pavel Размышления об оптимизаторах выглядят странно. Например рашморовский алгоритм был сначала в фоксе, потом его добавили в аксес, и уж только потом в MS SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 13:53 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
2 ЛП про 3 запрос он его именно выполняет 5 раз, а не выполнив 1 раз юзает данные для сравнения? Код: plaintext 1. 2. 3. А здесь он будет соответсвенно выполняться большее кол-во раз... это и требовалось доказать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 14:39 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Дык извини, но у тебя не в 3-м случае не один запрос, а пять разных. Как ты хочешь чтобы пять запросов за один раз исполнились? Как вариант у них могут быть даже разные планы выполнения. Максимум что может сделать аксес - запихать какие-нибудь промежуточные данные куда-нибудь в свою временную таблицу, но во-первых кто сказал, что он этого не делает, во-вторых если и не делает - это простительно для аксеса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 14:52 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Ну да... Запрос1 - в 3ем варианте выдаёт каждый раз одни и теже результаты и на х... его 5 раз гонять??? >во-вторых если и не делает - это простительно для аксеса. дааа... многое мы ему прощаем... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 15:04 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
>Запрос1 - в 3ем варианте выдаёт каждый раз одни и теже результаты и на >х... его 5 раз гонять??? человек в любом варианте рано или поздно помирает. и нах.. тогда жить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 15:10 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Я имел ввиду весь вложенный запрос, т.е. Select Top 1 B From [Запрос1] Where [Запрос1].А=[Таблица2].A А собственно Запрос1 если бы 5 раз исполнялся - вывелось бы 25 значений в дебуг, а не 5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 15:18 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Хотя последнее мое утверждение - не есть истина. В дебуг что-то пишется только при выборке конкретной строки, а вот откуда она выбирается - из уже готового запроса или только что выполненного - хз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 15:51 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
2 ЛП во-во ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:25 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
посм. т.1 стр.765-785 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:27 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
2 Хт Нетути т.1 и т.2 тоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:35 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
Хам, ты конечно мастер говорить загадками , но на работе у меня нет Гетца, а дома временно нет интернета :). Может могущественный джин и т.п. скажет в двух словах, что там писал Великий? Или мне придется номера страниц записать на бумажку и бояться ее потерять по дороге? Не говоря уже про тех, у кого Гетца нихт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:35 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
тама про план выполнения запросов написано (ShowPlan и ISAMStats). можно яво посмореть и как а такжа: как аксесс переваривает запросы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:45 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
2 Хам Спасибо за подробную инфу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 16:53 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
интересно, что на малом объеме он (акес) In(SELECT ...) обсчитывает так же как EXISTS (с передачей параметра внутрь). Что на некоторых SQL серверах не вернО. (времена расходятся на порядки - на больших объемах) Тест: данные: A.t - (a;b;c;d) B.t - (A;B;C) AABABCABCabc AABABCABCabc /* Public Function QueryTracing(value As String) As String Debug.Print value; QueryTracing = value End Function */ /* SELECT A.t, A.a, QueryTracing([t]) AS q FROM A WHERE A.t In (SELECT QueryTracing([t]) AS q FROM B); */ /* SELECT A.t, A.a, QueryTracing([t]) AS q FROM A WHERE Exists (SELECT * FROM B WHERE QueryTracing(B.t) =A.t); */ Именно поэтому, видимо конструкция с явной сшивкой In(строка) в Акесе работает быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2003, 19:26 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
2 assa Но всегда медленее чем JOIN имхо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 09:06 |
|
||
|
Теоритичиский вопрос по запросам
|
|||
|---|---|---|---|
|
#18+
У меня была проблема с Not IN (что JOIN-ами реализуется так: {(какой-нить)OUTER JOIN ... where ... is null}, и не во всех сложных запросах можно эдак сджойнить, а вот In() в WHERE воткнуть можно практически всегда, в некоторых случаях (не в Аксесе) допустимо даже {WHERE (f1,f2,...fn) {Not] In(SELECT f1,f2,...fn FROM ... )} (то же самое можно и с NOT EXISTS, но передачей значения(й) из строки во вложенный -т.е. заведомо построчным счетом). Такоже, если джойнить надо запрос (да еще с подзапросами) - могут (в том же аксесе) быть проблемы с уровнем вложенности. К тому же есть и чисто Акесовская проблема - когда в одном запросе приконнеченная табличка какого нить формата (например - какой-нить SQL -сервер, или тот же Btrieve) и акесовская. тогда, вместо того, чтоб джойнить (особо, если в In(Select .. FROM AccessTable ...) получается мало записей), шустрее прослать запрос + (масенький) набор, полученный из IN на выполнение серверу ("менеджеру" - в Btrieve). Но он (Акес) ведь этого не деет. Приходится руками (т.е. прогой) шить строку-перебор в In() (Выбрасывая "разноприродность" таблиц из запроса), а уж драйвер, похоже, просылает "простой" запрос серверу (даже когда не пишешь его как "запрос к серверу"). А в лоб, т.е. джойном - до второго пришествия считать будет. Данные туда-сюда по сетке гонять. (А это все обычные задачи слива данных откуда-то куда-то. Например - в тот же акес, или из него, или просто с его помощью). Зы. А джойном, обычно, и точно быстрее. Но, опять таки, JOIN, если он INNER, обычным WHERE пишется :0). И токо OUTER-ы дают действительную приятсвенность (по сравнению с WHERE). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2003, 13:04 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32260055&tid=1679504]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
54ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 327ms |

| 0 / 0 |
