Locate vs Select
Есть у меня некая база данных, к которой я подключаюсь через ADOConnection, к которому подключены Table и SQLQuery. Мне надо в таблице этой базы например найти запись, у которой выполняется определенное условие. Соответсвенно есть два пути решения: либо использовать метод Locate компонента Table, либо спомощью SQL-запроса компонента Query.
А вопрос в следующем, какой из этих методов работает быстрее? Или это по-сути одно и тоже?
Кто разбирался с этим, просвятите. :)
P.S. это для меня не критично, просто стало интересно. Да и на будущее может пригодиться не только мне. Ведь надо оптимизировать свои программы.
Есть у меня некая база данных, к которой я подключаюсь через ADOConnection, к которому подключены Table и SQLQuery. Мне надо в таблице этой базы например найти запись, у которой выполняется определенное условие. Соответсвенно есть два пути решения: либо использовать метод Locate компонента Table, либо спомощью SQL-запроса компонента Query.
А вопрос в следующем, какой из этих методов работает быстрее? Или это по-сути одно и тоже?
Кто разбирался с этим, просвятите. :)
P.S. это для меня не критично, просто стало интересно. Да и на будущее может пригодиться не только мне. Ведь надо оптимизировать свои программы.
TTable использовать не рекомендуется. Причины:
1. Прямое обращение к таблицам - практически всегда признак плохого проектирования.
2. Большой объем обмена данными с базой.
3. Дополнительный объем кода на фильтрацию и т.п.
Ну это уж слишком :)
kot_, спасибо за информацию, буду иметь в виду.
Есть у меня некая база данных, к которой я подключаюсь через ADOConnection, к которому подключены Table и SQLQuery. Мне надо в таблице этой базы например найти запись, у которой выполняется определенное условие. Соответсвенно есть два пути решения: либо использовать метод Locate компонента Table, либо спомощью SQL-запроса компонента Query.
А вопрос в следующем, какой из этих методов работает быстрее? Или это по-сути одно и тоже?
Кто разбирался с этим, просвятите. :)
P.S. это для меня не критично, просто стало интересно. Да и на будущее может пригодиться не только мне. Ведь надо оптимизировать свои программы.
Во-первых: какая СУБД? Если, например, в качестве СУБД используется Oracle, DB2 или MS SQL, SQL-конструкция "[FONT=Courier New]SELECT FIELD1 FROM TABLE1 WHERE FIELD2 = :PARAMETER1[/FONT]" по-любому будет выполняться быстрее, чем [FONT=Courier New]Table1->Locate()[/FONT], особенно, если по полю FIELD2 построен индекс (а если у нас Oracle, FIELD2 является Primary Key, и таблица не простая, а Index-Organized, то всё вообще просто летать будет).
Во-вторых: метод Locate, насколько я знаю, просто перебирает строки "от начала до обеда", т.е. пока не найдёт строку, удовлетворяющую критерию. Если надо ускорить поиск, создаём индекс по нужным полям (это "универсальный" совет, не зависящий от вида применяемой СУБД: хочешь ускорить выборку -- создай индекс, но будь готов к замедлению изменения данных) и используй [FONT=Courier New]Table1->Seek()[/FONT] (см. билдеровский хэлп).
В-третьих: если даже есть индекс, в большинстве случаев всё равно лучше использовать TQuery с соответствующим SQL-запросом, поскольку многие используемые "прослойки" между БД и нашей программой на самом деле транслируют прямые обращения к таблице в SQL-запрос вида "[FONT=Courier New]SELECT * FROM TABLE1[/FONT]".
В-четвёртых: в SQL-запросе в ряде случаев весьма желательно делать сортировку набора данных, т.е. писать SQL вида "[FONT=Courier New]SELECT FIELD1, FIELD2 FROM TABLE1 WHERE FIELD2 = :PARAMETER1 ORDER BY FIELD2[/FONT]". Тому есть несколько причин: если в качестве СУБД используется движок Paradox aka BDE, то он часто не использует существующий индекс для поиска и ищет по таблице полным перебором строк, если нет [FONT=Courier New]ORDER BY[/FONT] по тем же полям, по которым мы ищем; если используется тот же Oracle, то он не гарантирует, что порядок строк в возвращённом наборе данных будет тот же, как они физически располагаются в таблице, т.е. в каком порядке СУБД будет удобнее, в таком и выдаст.
1. Прямое обращение к таблицам - практически всегда признак плохого проектирования.
2. Большой объем обмена данными с базой.
Не совсем согласен. Если пишется "настольная" БД с хранением данных, например, в файлах формата DBF (иногда бывает нужно, скажем, для интеграции с устаревшим, но ещё используемым софтом), то работа с TTable бывает быстрее, чем с TQuery, надо только индексы нужные построить, и, естественно, использовать поиск по индексу.
Вот здесь ты прав...
База у меня в данной программе ACCESS'овская, но в ней я сейчас менять не буду, так как в той таблице записей не много (думаю их никогда более 50 не будет даже). Поэтому я думаю и LOCATE подойдет.
Но на будущее учту все сказанное знатоками.
Насчет DBF согласен, но знаю очень мало причин, по которым его надо использовать - слишком уж устаревший и громоздкий. Зачастую проще организовать работу на нормальной СУБД (благо выбор есть - среди эмбеддед серверов) - а для совместимости конвертить.
Хотя если нужные индексы построить - и запрос так же будет выполнятся пошустрее :) Так что, TTable все таки использовать стоит крайне редко даже с ДБФ.
Одну из причин я указал. :)