TTable vs TQuery

← →
ki11er (2003-03-03 13:41) [0]

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

← →
VAleksey (2003-03-03 13:47) [1]

TTable нужно использовать когда тебе нужна сложная обработка кождой записи.
TQuery для групповых операций и выборки по определенным условиям.

← →
Val (2003-03-03 14:22) [2]

>VAleksey © (03.03.03 13:47)
не совсем верно, думаю.
>ki11er (03.03.03 13:41)
поверьте, лучше почерпнуть это из литературы.

← →
Соловьев (2003-03-03 14:26) [3]

TTable легче использовать в смысле редактирования записей, для TQuery нужно все ручками делать... Как правило TTable используют для таблиц с небольшим кол-вом записей(от 1 до 100) - справочные таблицы, а TQuery - для работы с большими таблицами, ну и в принцыпе с
> VAleksey © (03.03.03 13:47)
> TTable нужно использовать когда тебе нужна сложная обработка
> кождой записи.

я не совсем согласен. Как раз SQL с некоторыми операциями справляется лучше и быстрее...

← →
sniknik (2003-03-03 14:41) [4]

Никто ни с кем несогласен, свою лепту внести чтоли? :-))
Ну не согласен я. (неважно с чем)

И Table и Query в случае для MSSQL полный отстой, нужно юзать ADOCommand и ADODataSet.
Для локального используемого Paradox, пофигу, что удобнее то и используй. Для пакетных обработок записей SQL побыстрее будет.

← →
msguns (2003-03-03 14:53) [5]

Для парадокса оптимальным является BDE.
Преимущество "запросной" технологии перед табличной в том, что сама физ.таблица гораздо меньше по времени находится в состоянии блокировки (т.е. в режиме вставки или изменения), отсюда бОльшая устойчивость БД в целом к "тормозам юзера". Ну и в плане последующего возможного перехода к другому формату БД такая технология более "дружественна", т.к. не требует коренного пересмотра логики приложения.
TTable интуитивно более понятна для разработчика, особенно не имеющего опыта работы в клиент-серверных системах. Расчитана на бОльшую, чем запросы, степень "владения" таблицей как физической сущностью и имеет некоторые методы и свойства, несовместимые с понятием запроса. Кроме того, не требуется наличие доп.ресурсов под обслуживание доступа, как это имеет место при запросах. Более пригодна для написания одно-двух-пользовательских систем.

Все - ИМХО

← →
ki11er (2003-03-03 16:23) [6]

Поставим вопрос по-джругому... Если в приложении, работающем в основном через TTable, заменить все это на TQuery с сответствующими запросами, то будет ли это более (или менее) надежно (частота поломки индексов, ...) и будет ли это более (или менее) быстро?

← →
ki11er (2003-03-03 16:24) [7]

Поставим вопрос по-другому... Если в приложении, работающем в основном через TTable, заменить все это на TQuery с сответствующими запросами, то будет ли это более (или менее) надежно (частота поломки индексов, ...) и будет ли это более (или менее) быстро?

← →
Соловьев (2003-03-03 16:28) [8]

Так у тебя Парадокс или MSSql?

← →
ki11er (2003-03-03 16:33) [9]

>Так у тебя Парадокс или MSSql?
;-))) У меня проблемы ;-)))
Изначально - парадокс. Но сейчас стоит задача, чтобы кроме парадокса работало еще и с MS SQL. Причем нужно сделать так, чтобы это было достаточно прозрачно - т.е. не было никаких доп. настроек (указали алиасом на SQL - работаем с SQL, указали алиасом на Paradox - работаем с Paradox)

← →
Карелин Артем (2003-03-03 16:35) [10]

>>будет ли это более (или менее) быстро?
where в SQL используется для удобства и скорости (если индекс есть).

А теперь представь ситуацию: таблица на 10 000 000. Нам нужна запись, стоящая где-то в конце. Мы знаем скажем идентификатор, и поле идентификатора индексировано. Сколько времени и памяти потребует Table?

← →
ki11er (2003-03-03 16:39) [11]

>А теперь представь ситуацию: таблица на 10 000 000.
В моем случае речь идет о таблице порядка 1000 записей. Ну максимум 100 000...

← →
Карелин Артем (2003-03-03 17:05) [12]

Удобство sql: любые сортировки без изврата типа создания индексов.
Насчет проблем с парадоксом не знаю, но сам давно только на SQL.

← →
Deniz (2003-03-03 17:33) [13]

Для меня однозначно TQuery - лучше, если сравнивать только эти компоненты.
Согласен с Карелин Артем © (03.03.03 16:35) с небольшим дополнением, если нужно "взять" и обработать 10% записей, затраты у TTable несравнимо больше чем TQuery.
А если система клиент-сервер, то от TTable вообще отказаться.

← →
sniknik (2003-03-03 17:44) [14]

ki11er (03.03.03 16:39)
> В моем случае речь идет о таблице порядка 1000 записей. Ну максимум 100 000...

Для MSSQL, пример,
нужна 1 запись из таблици, машина с SQL сервером в соседней комнате (только не говори, что у тебя по другому, это общий принцип клиент/сервер) открываем таблицу, по этому действию все записи этой таблици с сервера перекачиваются на клиента в память (~1000-100 000...), убивается трафик занимается память (нужна 1 не забыл еще?).
Почему такая лажа? Да потому что пытаемся с клиент/сервером работать как в локале, открыли таблицу отфильтровали/поиск получили нужную запись. А как надо?
Просто задаеш запрос с условием для этой 1 нужной записи. И получаеш с сервера именно ее. (1 <> 1000 не кажется?) трафик не засирается память по минимуму, работает только сервер на отборе записи но на то он и сервер.

ki11er (03.03.03 16:33)
> указали алиасом на SQL - работаем с SQL, указали алиасом на Paradox - работаем с Paradox
тогда работать нужно в любом случае как с клиент/сервером и никаких Тейблов. Но и в этом случае помучится придется, Paradox это не MSSQL, возьми вместо парадокса Access (более близок к MSSQL-ю)

← →
ki11er (2003-03-03 17:58) [15]

ok. спасибо.

TTable vs TQuery Найти похожие ветки