А>>по запросу с join'ом, со сложным условием, возможно, на каждую таблицу, входящую в dataset Что-то не хочется
А>по-другому никак

Присоединяюсь


А> но тебе не нужно делать несколько датаадаптеров. достаточно одного запроса, возвращающего несколько наборов, или процедуры.

А как сделать, чтобы второй, третий Resultset попадал в нужную мне таблицу, а не создавал новую "Table1"?

А>Вот это и есть то самое выполнение Join 2 раза (точнее, n раз — по числу таблиц) — которого мне не хотелось, но на которое придется идти, похоже.

У меня такая иерархия строится внутри SP во временных таблицах.

Сначала отбираю те объекты, которые наверняка нужны, потом для выбраных данных подтягиваю необходимые "атрибуты" из других таблиц.

В конце SP стоят несколько select'ов, которые и возвращают данные их временных таблиц — скопом подряд все несколько resultset'ов.


Получается, один запрос к БД, вызов SP с параметрами -> обработка на сервере, формирование ответа из нескольких таблиц -> затаскивание полного ответа.

PF>Бери один SQL/JOIN и потом скопируй мастер-часть в отдельную таблицу.

В отедельную временную таблицу. И всё это завернуть в Stored Procedure. Всё, идеальное круглое изолированное решение.

mihailik wrote:
> PF>Бери один SQL/JOIN и потом скопируй мастер-часть в отдельную
> таблицу.
>
> В отедельную временную таблицу. И всё это завернуть в Stored
> Procedure. Всё, идеальное круглое изолированное решение.

Нет, это может стать неоптимальным решением. Представь себе, 1 мастер-запись — 10 столбцов и 100 дочерных записей. Используя JOIN ты перекчиваешь 990 лишных значений по сравнению с двумя SELECT.

2 SELECT можно включить в одно SP и получить одной передачой две таблицы.

Peter

PF>2 SELECT можно включить в одно SP и получить одной передачой две таблицы.



Именно это я и имел в виду. У меня обе (вернее, их там четыре или пять штук) таблицы временные.

mihailik wrote:
> PF>2 SELECT можно включить в одно SP и получить одной передачой две
> таблицы.
...
> Именно это я и имел в виду. У меня обе (вернее, их там четыре или
> пять штук) таблицы временные.

Тогда все яно, хотя ты писал: "В отедельную временную таблицу.". Это я истолковал как JOIN в одну таблицы с последующим распределением данных в разные DataTable уже на клиенте.

Petere

M>В общем, самый дорогостоящий ресурс — канал связи. Пусть сервер там лопнет от натуги, но выдаст только нужные данные и без дублирования. И клиент, кстати, пусть объединяет все update/insert в один пакет. Такая вот кошерная парадигма. Кстати, была озвучена в MSDN Magazine с полгода назад.

Вот кстати, есть сомнения на эту тему. Иногда приличную лепту в общую стоимость вносит и число обращений к серверу.
Если надо выбрать — качать пять раз по 10 килобайт или один раз — 70 — то не исключено, что в конкретных условиях лучше будет второе.

Igor Trofimov wrote:
> M>В общем, самый дорогостоящий ресурс — канал связи. Пусть сервер там
> лопнет от натуги, но выдаст только нужные данные и без дублирования.
> И клиент, кстати, пусть объединяет все update/insert в один пакет.
> Такая вот кошерная парадигма. Кстати, была озвучена в MSDN Magazine с
> полгода назад.
>
> Вот кстати, есть сомнения на эту тему. Иногда приличную лепту в общую
> стоимость вносит и число обращений к серверу. Если надо выбрать -
> качать пять раз по 10 килобайт или один раз — 70 — то не исключено,
> что в конкретных условиях лучше будет второе.

А зачем 70 кбайт, если 50 достаточный. Нет необходимости эти 50 кбайт за пять обращений запрашивать.

Peter

PF>А зачем 70 кбайт, если 50 достаточный. Нет необходимости эти 50 кбайт за пять обращений запрашивать.

Ну, это я так.. к слову. О том, что не всегда только объем передаваемых данных важен.

Здравствуйте, Аноним, Вы писали:

А>Теперь пытаемся сделать это с помощью Typed dataset. Создаем новый dataset, перетаскиваем
А>в него одну таблицу, другую... Один DataAdapter, другой... Relations устанавливаем,
А>как положено... А как между ними задать этот самый join?

HOW TO: Implement a DataSet JOIN helper class in Visual C# .NET