TQuery против TTable

← →
Delphi basic © (2006-06-23 11:42) [0]

Для клиент-серверного приложения, когда желательно уменьшить объем сетевого трафика, в хелпах советуют использовать TQuery. А есть ли другие причины? Например, пусть имеется 1000 строк в таблице, из них отбирается 10. Что передается клиенту в каждом случае:
IBQuery - только 10 строк, отобраных SQL-запросом,
IBTable - вся 1000, из которой уже на клиенте отфильтровывается 10?

← →
Delphi basic © (2006-06-23 11:45) [1]

Просто раньше работал с помощью TTable. Теперь попробовал сделать то же самое с помощью TQuery - жутко неудобно. Во-первых, в листинг сразу влезает куча строк, в которых закидываются запросы; во-вторых, какие-либо изменения данных делать очень неудобно.

← →
Desdechado © (2006-06-23 11:58) [2]

Неудобно штаны через голову одевать. (с)
TQuery дает гибкость. Особенно на базах не из 1 таблицы, когда можно обратиться одним запросом и получить "выжимку" из многих табдиц по условиям и с сортировками, причем толькотех данных, какие нужны.
Обновления тоже делаются запросами, которые можно вписать заранее в соответствующие свойства (и обновления делаются автоматически) или отдельно для вящей гибкости обрабатывать руками.

← →
Ega23 © (2006-06-23 12:14) [3]

> попробовал сделать то же самое с помощью TQuery - жутко
> неудобно.

Ну если ты привык гланты вырезать через задницу - то конечно вырезать их через рот тебе будет жутко неудобно...

← →
Sergey13 © (2006-06-23 12:18) [4]

А чего не в "Потрепаться" сразу?

← →
Delphi basic © (2006-06-23 12:21) [5]

> IBQuery - только 10 строк, отобраных SQL-запросом,
> IBTable - вся 1000, из которой уже на клиенте отфильтровывается
> 10?

Насчет этого кто-нибудь может ответить?

← →
Ega23 © (2006-06-23 12:24) [6]

Так ты сам уже всё ответил...
СУБД, кстати, какая?

← →
Delphi basic © (2006-06-23 12:27) [7]

> Ega23 © (23.06.06 12:24) [6]
> Так ты сам уже всё ответил...
> СУБД, кстати, какая?

Вообще это был вопрос насчет того, так это или не так.
Тогда, получается, если в таблице 1млн. записей, из которых, допустим, нужно отобрать только 100, то TTable все их сначала затащит на клиента, а потом будет фильровать? жуть...
СУБД Firebird 1.5

← →
Sergey13 © (2006-06-23 12:30) [8]

2 [7] Delphi basic © (23.06.06 12:27)
>СУБД Firebird 1.5
Тогда твой ТТабл - это все равно законспирированный ЕКвери, только с дубово написанным запросом. Не умеют сервера по другому общаться, короме как на SQL.

← →
Danilka © (2006-06-23 12:31) [9]

[5] Delphi basic © (23.06.06 12:21)
Так и будет, если в IBQuery запрос, возвращающий только 10 записей, а в таблице, из которой отбираются данные 1000 записей.

Вообще, неплохо было-бы почитать теорию про РСУБД, ибо ТКвери и прочие, отличные от ТТабле это уже средство работы именно с РСУБД.

[6] Ega23 © (23.06.06 12:24)
> СУБД, кстати, какая?

Судя по IB% - IB :)

← →
Delphi basic © (2006-06-23 12:31) [10]

Так, а с deadlock"ами как быть?

← →
Danilka © (2006-06-23 12:31) [11]

[7] Delphi basic © (23.06.06 12:27)
> Тогда, получается, если в таблице 1млн. записей, из которых,
> допустим, нужно отобрать только 100, то TTable все их сначала
> затащит на клиента, а потом будет фильровать? жуть...

ага.

← →
Sergey13 © (2006-06-23 12:34) [12]

> [10] Delphi basic © (23.06.06 12:31)
> Так, а с deadlock"ами как быть?

Не допускать!!! 8-)

← →
Desdechado © (2006-06-23 12:35) [13]

> Так, а с deadlock"ами как быть?
вот так: ibase.ru

← →
Delphi basic © (2006-06-23 12:41) [14]

Как я понял, при работе с Query последовательность такая:
Пусть нужно отредактировать запись таблицы. Для редактирования берется текущая запись в DBGrid"е. Открываем окно, в котором поля записи раскидываются, допустим, по Edit"ам (DBEdit не идут, т.к. датасет нередактируемый (IBQuery)). После нажатия какой-нибудь кнопки закидываем их значения (пусть пока без проверки) в SQL.

DataModuleMain.IBSQL_Temp.Close;
DataModuleMain.IBSQL_Temp.SQL.Clear;
DataModuleMain.IBSQL_Temp.SQL.Add("update subdivision set code = """ +
EditCode.Text + """, name = """ + EditName.Text + """ where UI = " +
IntToStr(DataModuleMain.IBQuerySubdiv.FieldByname("UI").AsInteger));
DataModuleMain.IBSQL_Temp.ExecQuery;

← →
Danilka © (2006-06-23 12:45) [15]

[14] Delphi basic © (23.06.06 12:41)
Это один из кучи вариантов, причем, далеко не самый удачный. :)
Я-бы рекомендовал почитать что-нибудь. :)

← →
Sergey13 © (2006-06-23 12:45) [16]

2 [14] Delphi basic © (23.06.06 12:41)
>Как я понял, при работе с Query последовательность такая:
Это один из вариантов. Не самый плохой. Основной недостаток - необходимо переоткрыть исходный датасет для визуализации изменения на клиенте.

← →
Desdechado © (2006-06-23 12:46) [17]

Идея верна, реализация жутковата.

> DBEdit не идут, т.к. датасет нередактируемый (IBQuery)
Идут-идут. Только потом нужно почитать про значения свойств InsertSQL, UpdateSQL, DeleteSQL

← →
Delphi basic © (2006-06-23 12:51) [18]

> Идея верна, реализация жутковата.

Можно, конечно, и параметры использовать...
Да... по сравнению с Table код рааспухает прямо на глазах...

← →
Sergey13 © (2006-06-23 12:57) [19]

2[18] Delphi basic © (23.06.06 12:51)
> Да... по сравнению с Table код рааспухает прямо на глазах...
Это от незнания и от упертости в своем незнании.
Напиши у кверика в запросе
select * from table
(что собственно и происходит при использовании ТТабл),
и код обработки вообще не будет отличаться.

← →
Desdechado © (2006-06-23 13:03) [20]

> код рааспухает прямо на глазах...
За все нужно платить. За гибкость - особенно.
Ttable - для ленивых. Если ты такой, забудь все говоренное тебе, пользуйся своей ленью.

← →
Delphi basic © (2006-06-23 13:28) [21]

> Sergey13 © (23.06.06 12:57) [19]
> 2[18] Delphi basic © (23.06.06 12:51)
> > Да... по сравнению с Table код рааспухает прямо на глазах.
> ..
> Это от незнания и от упертости в своем незнании.
> Напиши у кверика в запросе
> select * from table
> (что собственно и происходит при использовании ТТабл),
> и код обработки вообще не будет отличаться.

Так я у квери так и записал. Просто данные из таблицы отбираются одним квери, а апдейты, инсерты и делейты - другим.

← →
Delphi basic © (2006-06-23 13:31) [22]

А может, все это делать через StoredProc?

← →
Desdechado © (2006-06-23 13:34) [23]

а, может, почитать книжки?

> Desdechado © (23.06.06 13:34) [23]
> а, может, почитать книжки?

Я их в свое время жуткое количество перечитал. Жалко, тогда по программированию не попадались :)

Всем спасибо за советы и обоснованную критику.
Я понял, что от Query мне никуда не деться :)

> Просто данные из таблицы отбираются одним квери, а апдейты,
> инсерты и делейты - другим.

А [17] в игнор попал? За что ж?

← →
Виталий Панасенко (2006-06-23 16:02) [28]

> Delphi basic © (23.06.06 13:49) [26]
> Всем спасибо за советы и обоснованную критику.
> Я понял, что от Query мне никуда не деться :)
>

Используй IBDataSet, и смотри
> Desdechado © (23.06.06 12:46) [17]
> Идея верна, реализация жутковата.
>
> > DBEdit не идут, т.к. датасет нередактируемый (IBQuery)
> Идут-идут. Только потом нужно почитать про значения свойств
> InsertSQL, UpdateSQL, DeleteSQL

> > Delphi basic © (23.06.06 13:49) [26]
> > Всем спасибо за советы и обоснованную критику.
> > Я понял, что от Query мне никуда не деться :)
> >
>
> Используй IBDataSet, и смотри
> > Desdechado © (23.06.06 12:46) [17]
> > Идея верна, реализация жутковата.
> >
> > > DBEdit не идут, т.к. датасет нередактируемый (IBQuery)
> > Идут-идут. Только потом нужно почитать про значения свойств
>
> > InsertSQL, UpdateSQL, DeleteSQL

В общем, поставил я FIBPlus. Более менее разобрался.
Правда, вот на что внимание обратил. Посмотрел я, как в одной довольно серьезной системе реализована параллельная работа пользователей - жуть.
Ситуация: есть документ.
1) Юзер 1 открывает его для редактирования.
2) Юзер 2 открывает его для редактирования.
3) Юзер 1 сохраняет изменения.
4) Юзер 2 сохраняет изменения.
5) Юзер 1 открывает тот же документ и очень удивляется увиденному
(а почему бы системе в момент открытия уже редактируемого кем-то док-та
не предупредить об этом юзера 2 и не запретить редактирование? Юзер 1, может, ночь не спал, редактируя его?)

Меня возможность такой коллизии в довольно серьезной системе (используется в электроэнергетике и нефтяной отрасли) очень неприятно удивила...

>Посмотрел я, как в одной довольно серьезной системе реализована параллельная работа пользователей - жуть.

На любой связке БД-компоненты такое можно сделать. А можно не сделать. 8-)

> > Тогда, получается, если в таблице 1млн. записей, из которых,
>
> > допустим, нужно отобрать только 100, то TTable все их
> сначала
> > затащит на клиента, а потом будет фильровать? жуть...
>
> ага.

О сколько нам открытий чудных готовит просвещенья дух.

> а почему бы системе в момент открытия уже редактируемого кем-то док-та
Это или неверное проектирование (когда не выяснили бизнес-процессы и возможность одновременной работы над документом для разруливания оного), или неверно розданные полномочия (например, когда пользователи работают на запись только со своими документами и нет "общих").

И это, кстати, никоим образом не касается сервера БД, на котором реализована программа.

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