![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Правильно отфильтровать поля [D7, Access]
Дядя Вова © (2007-12-19 11:50:00)Здравствуйте.
Такой вопрос:
Есть две таблицы связанные через массу промежуточных. Необходимо поля первой отфильтровать через поля второй.
Правильно ли я понимаю, что ЕДИНСТВЕННЫЙ метод это сделать запрос через внутреннее объединение всех таблиц и применить WHERE?
Т.е.
SELECT * FROM (((table1 INNER JOIN table5 ON ...)) INNER JOIN table6 ON ...) INNER JOIN table2 ON ...) WHERE table2.id > 5;
Насколько медленно будет работать такой запрос при 1000 записях в каждой таблице?
sniknik (2007-12-19 15:59:00) [1]не время выполнения, а время фетча, т.е. время закачки данных на клиента. разные вещи.
и неважно, что в твоем случае сервер и клиент это одна и таже машина, передача данных через движок (ядро) все одно присутствует. и вообще лучше рассматривать jet как своего рода сервер, и работать с ним по принципам клиент сервера а не файл сервера (хотя у него и есть исключения но пока это лучше не рассматривать).
Дядя Вова (2007-12-19 15:50:00) [2]
> SELECT * при большом количестве полей и соединении многих
> таблиц может дать нехилый по времени фетч.
Т.е. SELECT table2.field1 FROM .....
в разы сократит время выполнения?
sniknik (2007-12-19 14:11:00) [3]> Последнее, если кто сталкивался будет ли время такого запроса измеряться в секундах, если около 1000 записей в каждой таблице?
> БД Access
практика критерий истины!...
и вообще, недостаточно инфы чтобы сказать хотя бы примерно... (а даже если бы было достаточно, то кто будет воспроизводить твою ситуацию, писать записи (по 1000), и т.д. проверять только чтобы тебе это передать? сам с успехом справишься... или в дворники.)
для примера сталкивался с идиотской на первый вгляд ситуацией (и вроде бы с базой аксесс) когда одно и тоже по сути условие в разных вариантах давало время выполнения на порядки различающиеся, типа минута vs секунда... а условие связей (и инфа по полям в них) у тебя даже не показано, типа как несущественное...
кому интересно условие было такое
... WHERE isTrueInBoolField
тормозило, а переписанное так
... WHERE isTrueInBoolField=true
"летало".
Desdechado (2007-12-19 13:59:00) [4]
SELECT *при большом количестве полей и соединении многих таблиц может дать нехилый по времени фетч.
Sergey13 (2007-12-19 13:56:00) [5]> [6] Дядя Вова (19.12.07 13:52)
> будет ли время такого запроса измеряться в секундах
Ну не в литрах же. Естественно в секундах. Или в сутках - то-же можно. 8-)
Kolan (2007-12-19 13:53:00) [6]> если кто сталкивался будет ли время такого запроса измеряться
> в секундах, если около 1000 записей в каждой таблице?
> БД Access
Куда проще проверить
Дядя Вова (2007-12-19 13:52:00) [7]В целом ответ получил, спасибо.
Последнее, если кто сталкивался будет ли время такого запроса измеряться в секундах, если около 1000 записей в каждой таблице?
БД Access
Sergey13 (2007-12-19 13:27:00) [8]> [3] Дядя Вова (19.12.07 12:06)
> Запрос выписан,
Запрос не накладная - его не выпишешь. 8-)
>связь FK = PK.
Это еще ни о чем не говорит. Если PK=индекс, то FK<>индекс.
sniknik (2007-12-19 12:30:00) [9]> что ЕДИНСТВЕННЫЙ метод
ну почему? можно еще через подзапросы (при малых количествах выбираемых записей возможно будет даже выигрыш в скорости)
> Насколько медленно будет работать такой запрос при 1000 записях в каждой таблице?
проверь, и узнаешь...
> Хотелось бы узнать какое правильное решение в подобных ситуациях.
нормальное решение... раз уж работает и удовлетворяет. если нет, то пробуй варианты, вплоть до перепланировки структуры базы. (может немного денормализовать не помешает...)
Дядя Вова (2007-12-19 12:06:00) [10]
> Это зависит от запроса и структуры таблиц/индексов
Запрос выписан, связь FK = PK.
Хотелось бы узнать какое правильное решение в подобных ситуациях.
Jeer (2007-12-19 12:04:00) [11]
> Есть две таблицы связанные через массу промежуточных.
Скорее всего проблема в дизайне БД.
Sergey13 (2007-12-19 11:57:00) [12]> [0] Дядя Вова (19.12.07 11:50)
> Насколько медленно будет работать такой запрос при 1000
> записях в каждой таблице?
Это зависит от запроса и структуры таблиц/индексов