быстрее ли SQL чем стандартный перебор всей таблицы

← →
Relaxxx © (2003-10-13 18:12) [0]

Мастера вот такой вопрос

Есть например таблица с 150 000 записей. нужно например выбрать все записи где дата дольше ДАТА1 и меньше ДАТА2. Мне тут утверждают (помоему это глупо), что если я например напишу на Делфи этот запрос через БДЕ используя компонент Query1, а например другой чел сделает в VisualC++ таким образом получить доступ к таблице используя ODBC или DAO и потом пройля в цикле всю таблицу и проверяя удовлетворяет ли данная запись условию, если да то отобразить в таблице.
Так вот чей метод быстрее, помоему с помощью SQL запроса будет раз 20 быстрее, а проверить сейчас нет времени

← →
Vlad © (2003-10-13 18:15) [1]

Пускай этот чел на своем C++ дальше так и работает.
А ты его не слушай. Это не наш метод :)))

← →
Relaxxx © (2003-10-13 18:45) [2]

а вообще если серьезно, что быстрее будет??

← →
Sandman25 © (2003-10-13 18:53) [3]

При переборе всех записей таблицы на клиентскую машину тащится вся таблица.
При использовании SQL на клиентскую машину тащятся только нужные записи.

← →
Johnmen © (2003-10-13 18:55) [4]

>...что быстрее будет??

Нужет полный список условий для обоих случаев. И как определяются моменты пуска и стопа секундомера...:)

← →
Relaxxx © (2003-10-13 18:56) [5]

тоесть вы хотите сказать что разница небольшая и почти не заметная

← →
Sandman25 © (2003-10-13 18:57) [6]

тащятся -> тащатся
Ча-ща с буквой "а" :(

← →
Delirium © (2003-10-13 19:27) [7]

Для 150 000 записей разница будет колоссальной, практически для любой БД поддерживающей SQL.

← →
NikB (2003-10-14 01:32) [8]

Mojno i ne ponial vopros, no v vopros ne govoritsa o client/server, a esli rech idet ne o client/server, a o local"noi comp - to na Delhi toje ne budut problemi:
"получить доступ к таблице используя !!!BDE!!! и потом пройля в цикле всю таблицу и проверяя удовлетворяет ли данная запись условию, если да то отобразить в таблице"
i tak budet bistree, a esli uslovia (SQL where) bolshie - esche biistree budet v cikle.

← →
Е-Моё имя © (2003-10-14 01:38) [9]

имхо SQL движок должен быстрее делать в любом случае

← →
Reindeer Moss Eater © (2003-10-14 08:52) [10]

Не в любом случае.

← →
Е-Моё имя © (2003-10-14 08:57) [11]

например если движок кривой? ;))

← →
Sergey13 © (2003-10-14 09:01) [12]

Если присовокупить индекс к запросу, то однозначно быстрее. Если без индекса, то нужно мерять (для локальной БД), но SQL все таки победит, ИМХО. Для серверной БД, SQL однозначно шустрее.

← →
Reindeer Moss Eater © (2003-10-14 09:05) [13]

Есть например таблица с 150 000 записей. нужно например выбрать все записи где дата дольше ДАТА1 и меньше ДАТА2.

Если все записи удовлетворяют этому условию, то файл-сервер и клиент-сервер будут работать примерно одинаково

← →
DenK_vrtz © (2003-10-14 09:08) [14]

Делал я когда то такой эксперимент, интересно было. Поиск по локальной таблице без индексов.
Искомая запись была где-то в конце списка, записей было порядка 800 (не много!). Так вот сплошной перебор с "отключенными" визуальными компонентами заметно тормозил, а sql-запрос делал все влет.

← →
Reindeer Moss Eater © (2003-10-14 09:23) [15]

DenK_vrtz ©

В случае локальных таблиц при использовании SQL и навигационных методов выполняется примерно один и тот же код. Так что результаты эксперимента скорее всего недостоверны.

← →
Anatoly Podgoretsky © (2003-10-14 09:26) [16]

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

← →
DenK_vrtz © (2003-10-14 09:29) [17]

Reindeer Moss Eater ©
Anatoly Podgoretsky ©

но факт остается фактом!

← →
Reindeer Moss Eater © (2003-10-14 09:34) [18]

DenK_vrtz

Этот факт говорит лишь об одном: Твой конкретный навигационный код находил нужную запись медленнее чем твой конкретный LocalSQL запрос.

← →
DenK_vrtz © (2003-10-14 09:38) [19]

Reindeer Moss Eater, :)

← →
Anatoly Podgoretsky © (2003-10-14 10:06) [20]

Это всего лишь означает, что для LocalSQL набор был у тебя в памяти.

← →
Izyum © (2003-10-14 10:25) [21]

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

← →
Reindeer Moss Eater © (2003-10-14 10:29) [22]

Если мне память не врет, для настольных баз даже при использовании SQL данные ВСЕ затягиваются в клиентскую память,

Память (твоя) здесь ни причем.
Здесь причем здравый смысл.
Если в настольных базах некому обрабатывать данные БД кроме как процессору клиентской машины, то значит ВСЕ эти данные должны быть на локальной машине прежде чем будут обработаны.

> Reindeer Moss Eater © (14.10.03 10:29) [22]

Во-во... а посему, TTable лучше использовать. А TQuery токмо для выборок со сложными фильтрами, которые через механизм фильтрации TTable реализовать сложно.

Механизм фильтрации в БДЕ много можнее возмодностей SQL, есои точнее то ограничением является только фантазия.

Relaxxx ©
Спроси у своего товарища, что быстрее
1) SQL запрос по индексу
2) Полный перебор записей, с фетчем на клиента
Интересно, что он ответит :)))

Друзья, о чем вы спорите?? Ведь автор не уточнил какая БД имеется в виду!!
Удивлен такой невнимательности.

Автор, ау: какая БД имеется в виду? Только не говорите, что "какая-нибудь, любая", т.к. для "вообще" и ответ один: всяко может повернуться.

PS
А VC++ или дельфи - это вообще отдельная тема обсуждения и уточнения, т.к. не понятно что в каждом конкретном случае будет использоваться для доступа к БД.

>KSergey © (14.10.03 12:33) [26]
Зато автор уточнил кол-во записей в БД.
Уверяю, фетч такого кол-ва на клиент с последующей проверкой займет намного больше времени чем SQL запрос по индексу.
Думаю, тут даже тип БД не причем.

[27] Vlad © (14.10.03 12:37)
Зато автор уточнил кол-во записей в БД.
Уверяю, фетч такого кол-ва на клиент с последующей проверкой займет намного больше времени чем SQL запрос по индексу.
Думаю, тут даже тип БД не причем.

Замечательно!
А где вообще сказано про "клиентов", "серверов" и т.д.??
Может это база из DBF-файлов прямо на этой же машине лежит под боком, а? Можно подумать на SQL-серверах свет клином сошелся.

>потом пройля в цикле всю таблицу и проверяя удовлетворяет ли данная запись условию,
Вот что написал автор.
И причем тут DBF или не DBF ?
Пройти в цикле всю таблицу сколько времени займет ?
А индексированный поиск ?
Естественно учитываем кол-во записей, приведенное автором.

Я так понял, что обсуждаются все же локалки, - в клиент-серверах такой вопрос наивен.
Могу поделиться опытом работы с парадоксом. Выборка (особенно при Update) идет очень долго, если в условиях нет ключей (Primary) или индексов, а одно или более полей в условии имеют длинный симв.формат. В этом случае время выполнения запроса сопоставимо с построчным сравнением всех записей таблицы.
Если же в условиях запроса есть ключевые поля (особенно первичные), то выполняется такой запрос в десятки, а то и сотни раз быстрее. Отсюда вывод - стараться проектировать БД таким образом, чтобы поля, подобные приведенным в сабже датам, включались в первичный ключ или входили в индекс.

Большую роль играет еще такой факт, как сложный запрос, т.е. более чем по одной таблице. В этом случае получается матрица (N*M*P*...), где N - кол-во записей в 1-й таблице, N - 2-й и т.д.
Зависимость продолжительности запроса от размерности этой матрицы отнюдь не линейная и опять же зависит от того, являются ли связующие поля ключевыми.

В общем же случае, конечно, перебор записей менее эффективен. Хотя бы потому, что при нем не используются механизмы ключей и индексов.

Кстати,
KSergey © (14.10.03 12:33) [26]
Друзья, о чем вы спорите?? Ведь автор не уточнил какая БД имеется в виду!!
Удивлен такой невнимательности.

Вот из этого я и сделал вывод, что используется клиент-сервер. А именно Оракл.
получить доступ к таблице используя ODBC или DAO и потом...
Это к вопросу о невнимательности.

Так может прежде чем гадать дождемся, когда автор соизволит напрячься и написать четко и конкретно что он имел в виду?

быстрее ли SQL чем стандартный перебор всей таблицы Найти похожие ветки