Соединяющие запросы в .Net и Delphi

← →
by © (2004-12-06 15:25) [0]

Есть как минимум два варианта получения данных в клиентское приложение. Пример.
У нас есть таблица оплат клиентов Pmnt и таблица самих клиентов Person
Pmnt
PmntID PersonID SumPmnt PmntDt
100 10 20 10.10.04
101 10 30 11.10.04
102 11 25 11.10.04
..................
1000 10 100 30.10.04

Person
PersonID Name
10 Иванов
11 Петров
...

Первый способ получения данных на клиента

Мы можем составить запрос вида
Select C.Name, P.PmntDt, P.SumPmnt
From Pmnt P, Person C
Where P.PersonID=C.PersonID

и получить на выходе на клиенте таблицу вида
C.Name P.PmntDt P.SumPmnt
Иванов 10.10.04 20
Иванов 11.10.04 30
Петров 11.10.04 25
...

==========

Второй способ.
Мы получаем отдельно на клиента выборку из Pmnt и соответствующие им Person и через LookupField (в Delphi) или DataSet/DataTable (.Net) соединяем.

При первом способе у нас в минусах избыточный трафик, а при втором - проблемы с фильтрицией и сортировкой.

Какие методы используете вы? и причины этого

← →
Petr V. Abramov © (2004-12-06 16:10) [1]

> При первом способе у нас в минусах избыточный трафик
Избыточный трафик будет, если выбрать все оплаты всех клиентов. Это кому-нить нужно? Это реально просмотреть и не утонуть?

← →
Petr V. Abramov © (2004-12-06 16:10) [2]

← →
by © (2004-12-06 16:15) [3]

Petr V. Abramov © (06.12.04 16:10) [2]
Ну а если по каждому клиенту за период отбора по 100 записей и нужно не только Наименование клиента показываеть, но и код и еще какую-то инфу. Тогда же избыточный трафик будет?

← →
by © (2004-12-06 16:26) [4]

Этот вопрос я поднял потому что в книге Девида Сеппа ADO.NET подход раздельных запросов описан как более правильный. Вот и интересно мнение.

← →
Sergey13 © (2004-12-06 16:34) [5]

Второй способ использую иногда, обычно когда лукапный (справочный) НД не большой. Иначе, для показа запроса по 1 (10,20) человеку тащится на клиента весь справочник людей, а там может и 1000 и 2000 и 1000000 записей. Хотя иногда бывает выгоднее закачать весь справочник. В общем, по обстоятельствам.

← →
Petr V. Abramov © (2004-12-06 16:35) [6]

by © (06.12.04 16:15) [3]
> Ну а если по каждому клиенту за период отбора по 100 записей и
> нужно не только Наименование клиента показываеть, но и код и
> еще какую-то инфу. Тогда же избыточный трафик будет?
При небольшой выборке ( а только небольшие имеют право на жизнь), боюсь, этот избыточный трафик будет сопоставим с трафиком на отправку нового запроса. И несопоставим с геморроем при втором варианте

> подход раздельных запросов описан как более правильный. Вот и
> интересно мнение.
мнение - заговор производителей памяти. Которая будет тратиться на join на клиенте (уверен, не лучшим образом реализованный).

Petr V. Abramov © (06.12.04 16:35) [6]
Но на клиенте join будет наверное только в момент отображения запис на экране.

Хотя тот же Сеппа говорит что раздельные запросы очень удобны для редактирования данных, в самом датасете. Я так не делаю, список для отображения, а для редактирования - выбирается отдельная запись. Может если не редактировать в списке/гриде, тогда и преимущества раздельного подхода теряются.

2[7] by © (06.12.04 16:39)
>Я так не делаю, список для отображения, а для редактирования - выбирается отдельная запись.
А потом обновляешь запрос для отображения. Вот и трафик полез. 8-)

> а для редактирования - выбирается отдельная запись.
> А потом обновляешь запрос для отображения. Вот и трафик полез. 8-)

А зачем обновлять - CachedUpdates и нормально. При выборке отдельной записи ее как раз и for update святое дело выбрать

Соединяющие запросы в .Net и Delphi Найти похожие ветки