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

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

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

TTable vs TQuery [D4, MSSQL, Paradox]

ki11er © (2003-03-03 13:41:00)
Хочется узнать сравнительную оценку этих компонентов (скорость, надежность, ...). В каких случаях нужно использовать первый и в каких второй?

ki11er (2003-03-03 17:58:00) [1]
ok. спасибо.

sniknik (2003-03-03 17:44:00) [2]
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-ю)

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

Карелин Артем (2003-03-03 17:05:00) [4]
Удобство sql: любые сортировки без изврата типа создания индексов.
Насчет проблем с парадоксом не знаю, но сам давно только на SQL.

ki11er (2003-03-03 16:39:00) [5]
>А теперь представь ситуацию: таблица на 10 000 000.
В моем случае речь идет о таблице порядка 1000 записей. Ну максимум 100 000...

Карелин Артем (2003-03-03 16:35:00) [6]
>>будет ли это более (или менее) быстро?
where в SQL используется для удобства и скорости (если индекс есть).

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

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

Соловьев (2003-03-03 16:28:00) [8]
Так у тебя Парадокс или MSSql?

ki11er (2003-03-03 16:24:00) [9]
Поставим вопрос по-другому... Если в приложении, работающем в основном через TTable, заменить все это на TQuery с сответствующими запросами, то будет ли это более (или менее) надежно (частота поломки индексов, ...) и будет ли это более (или менее) быстро?

ki11er (2003-03-03 16:23:00) [10]
Поставим вопрос по-джругому... Если в приложении, работающем в основном через TTable, заменить все это на TQuery с сответствующими запросами, то будет ли это более (или менее) надежно (частота поломки индексов, ...) и будет ли это более (или менее) быстро?

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

Все - ИМХО

sniknik (2003-03-03 14:41:00) [12]
Никто ни с кем несогласен, свою лепту внести чтоли? :-))
Ну не согласен я. (неважно с чем)

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

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

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

Val (2003-03-03 14:22:00) [14]
>VAleksey © (03.03.03 13:47)
не совсем верно, думаю.
>ki11er (03.03.03 13:41)
поверьте, лучше почерпнуть это из литературы.

VAleksey (2003-03-03 13:47:00) [15]
TTable нужно использовать когда тебе нужна сложная обработка кождой записи.
TQuery для групповых операций и выборки по определенным условиям.

Наверх

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