Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Relaxxx © (2003-10-13 18:12:00)

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

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

KSergey (2003-10-14 14:16:00) [1]

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

Vlad (2003-10-14 14:03:00) [2]

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

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

MsGuns (2003-10-14 13:48:00) [3]

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

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

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

Vlad (2003-10-14 13:13:00) [4]

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

KSergey (2003-10-14 13:07:00) [5]

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

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

Vlad (2003-10-14 12:37:00) [6]

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

KSergey (2003-10-14 12:33:00) [7]

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

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

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

Vlad (2003-10-14 11:06:00) [8]

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

Anatoly Podgoretsky (2003-10-14 11:02:00) [9]

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

Izyum (2003-10-14 10:34:00) [10]

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

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

Reindeer Moss Eater (2003-10-14 10:29:00) [11]

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

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

Izyum (2003-10-14 10:25:00) [12]

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

Anatoly Podgoretsky (2003-10-14 10:06:00) [13]

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

DenK_vrtz (2003-10-14 09:38:00) [14]

Reindeer Moss Eater, :)

Reindeer Moss Eater (2003-10-14 09:34:00) [15]

DenK_vrtz

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

DenK_vrtz (2003-10-14 09:29:00) [16]

Reindeer Moss Eater ©
Anatoly Podgoretsky ©

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

Anatoly Podgoretsky (2003-10-14 09:26:00) [17]

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

Reindeer Moss Eater (2003-10-14 09:23:00) [18]

DenK_vrtz ©

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

DenK_vrtz (2003-10-14 09:08:00) [19]

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

Reindeer Moss Eater (2003-10-14 09:05:00) [20]

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »