Есть задача: получить из двух таблиц некоторую вырезку. Например:

Use Northwind
Select Employees.EmployeeID, Orders.OrderID from Employees 
        join Orders on Employees.EmployeeID = orders.EmployeeID
    where Employees.LastName = 'Fuller' And Orders.ShipVia = 2

Получаем 36 строк, отображающих нужную нам информацию.

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

В первую —

Select Employees.EmployeeID from Employees where Employees.LastName = 'Fuller'

Во вторую —

Select Orders.OrderID from Orders where Orders. ShipVia = 2

,

Либо же делать на каждый DataAdapter свой запрос:

Select Employees.EmployeeID from Employees 
        join Orders on Employees.EmployeeID = orders.EmployeeID
    where Employees.LastName = 'Fuller' And Orders.ShipVia = 2

и, соответственно,

Select Orders.OrderID from Employees 
        join Orders on Employees.EmployeeID = orders.EmployeeID
    where Employees.LastName = 'Fuller' And Orders.ShipVia = 2

В первом случае получаем оверхед по передаче данных, во втором — два запроса вместо одного,
и это еще хорошо, что таблиц всего две, а запросы — тривиальные.
Вопрос: как сложный join-запрос по нескольким таблицам с большим количеством данных
загнать в dataset? Или dataset'ы для этого вообще не предназначены?

А>В первом случае получаем оверхед по передаче данных, во втором — два запроса вместо одного,
А>и это еще хорошо, что таблиц всего две, а запросы — тривиальные.
А>Вопрос: как сложный join-запрос по нескольким таблицам с большим количеством данных
А>загнать в dataset? Или dataset'ы для этого вообще не предназначены?

Забей ты на них Дольше искать будешь место, где они хорошо лягут, эти DataSet'ы, а особенно typed. Имхо.
Все более-менее сложные операции — делай на серваке. DataSet — не локальная СУБД.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Забей ты на них Дольше искать будешь место, где они хорошо лягут, эти DataSet'ы, а особенно typed. Имхо.
iT>Все более-менее сложные операции — делай на серваке. DataSet — не локальная СУБД.

А какая разница, на серваке, на клиенте? Вопросы-то те же самые остаются....
Можно, конечно, dataset'ы совсем не использовать... Но уж больно вкусная вещь,
особенно с точки зрения иерархии, жаль отказываться...

А>В первом случае получаем оверхед по передаче данных, во втором — два запроса вместо одного,
А>и это еще хорошо, что таблиц всего две, а запросы — тривиальные.
А>Вопрос: как сложный join-запрос по нескольким таблицам с большим количеством данных
А>загнать в dataset? Или dataset'ы для этого вообще не предназначены?
Как ты хочешь отобразить в датасете один набор данных в виде нескольких таблиц? Сделай команду, возвращающую несколько наборов, и грузи в датасет их

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


А>Как ты хочешь отобразить в датасете один набор данных в виде нескольких таблиц? Сделай команду, возвращающую несколько наборов, и грузи в датасет их

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

...
> В первом случае получаем оверхед по передаче данных, во втором — два
> запроса вместо одного, и это еще хорошо, что таблиц всего две, а
> запросы — тривиальные. Вопрос: как сложный join-запрос по
> нескольким таблицам с большим количеством данных загнать в dataset?
> Или dataset'ы для этого вообще не предназначены?

Ты должен по-другому подходить: Какая у тебя задача?

Ты можешь загнать в одну DataTable все записи от одного только Select/Join. Почему тебе надо сделать несколько запросов?

Если хочешь сократить объем загрузки, то можешь в случае 1:n-Relation использовать несколько запросов аналогично твоему второму варианту и добавить relation object. Это как раз очень удобный и эффективный вариант.

Peter

Здравствуйте, Peter Fleischer, Вы писали:


PF>Ты должен по-другому подходить: Какая у тебя задача?

Из нескольких таблиц получить данные, соответствующие тем, что получаются при join'e, но, в идеале, в иерархически-связном формате, который предоставляется datasetam'и. Нужно для последующего внутрипрограммного (возможно, юзеринтерфейсного) неспешного и вдумчивого лазания по ним, добавления/удаления/исправления. после окончания обработки — за один (ладно, ладно, за число DataAdapter'ов) раз заливания всего этого в базу.

PF>Ты можешь загнать в одну DataTable все записи от одного только Select/Join. Почему тебе надо сделать несколько запросов?

В одну — мне не надо. Мне в несколько, связанные relation'ами. То есть то, что Dataset предлагает (или пытается предложить, согласно MS-ным заявлениям). В одну — это я и так могу: один запрос, у себя на клиенте разобрать по объектам, отследить изменен/удален/вставлен, попинать SQL по результатам отслеживания... Только при чем здесь декларируемые преимущества Dataset'а по работе с несколькими таблицами?

PF>Если хочешь сократить объем загрузки, то можешь в случае 1:n-Relation использовать несколько запросов аналогично твоему второму варианту и добавить relation object. Это как раз очень удобный и эффективный вариант.

А если там не 1:n? Если там больше двух таблиц? Если условия на них такие, что запрос уже выполняется время, которое надо во внимание принимать? А тут еще его придется (один и тот же запрос ведь, на самом деле) выполнять столко раз, сколько таблиц в него включено. Как то это... Неаккуратненько...

А>Можно, конечно, dataset'ы совсем не использовать... Но уж больно вкусная вещь,
А>особенно с точки зрения иерархии, жаль отказываться...

Вкусная? Или тебе рассказали, какая она вкусная?
Знаешь, что я тебе посоветую? Ты попробуй тот, другой, третий вариант. Возможно даже четвертый и пятый. Что бы потом, если что, меньше переделывать. Попробуй потом поиграться с этими вариантами на предмет удобства внесения изменений — например, поля поменять в табличке. Посмотри на трафик. И все такое.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Знаешь, что я тебе посоветую? Ты попробуй тот, другой, третий вариант. Возможно даже четвертый и пятый. Что бы потом, если что, меньше переделывать. Попробуй потом поиграться с этими вариантами на предмет удобства внесения изменений — например, поля поменять в табличке. Посмотри на трафик. И все такое.

Я могу попробовать. Тот, и другой, и третий. И даже четвертый и пятый. Но перед этим я хочу знать, рекомендовано ли какое-либо решение подобной проблемы Microsoft'ом (не нашел ни в MSDN'е, ни в интернете); либо присутствует ли какой-либо опыт у народа, сталкивавшегося уже с данным вопросом . А сам я, если уж на то пошло. склоняюсь к старому доброму тривиальному способу : все делать самому, ручками. За один запрос через join все получить, у себя разобрать по объектам, изменения — тоже самому отслеживать. Хлопотно, зато лишней нагрузки на сервер не будет

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

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


А>>Как ты хочешь отобразить в датасете один набор данных в виде нескольких таблиц? Сделай команду, возвращающую несколько наборов, и грузи в датасет их

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

> Здравствуйте, Peter Fleischer, Вы писали:
>
> PF>Ты должен по-другому подходить: Какая у тебя задача?
>
> Из нескольких таблиц получить данные, соответствующие тем, что
> получаются при join'e, но, в идеале, в иерархически-связном формате,
> который предоставляется datasetam'и. Нужно для последующего
> внутрипрограммного (возможно, юзеринтерфейсного) неспешного и
> вдумчивого лазания по ним, добавления/удаления/исправления. после
> окончания обработки — за один (ладно, ладно, за число DataAdapter'ов)
> раз заливания всего этого в базу.

Если нужна иерархия, то тебе нужно несколько DataTable в DataSet и Relations! Загрузить можно одным SQL/JOIN с последующим программным разпределением или несколькими загрузкам, что более выгодно, когда 1:n.отношения.

...
> PF>Если хочешь сократить объем загрузки, то можешь в случае
> 1:n-Relation использовать несколько запросов аналогично твоему
> второму варианту и добавить relation object. Это как раз очень
> удобный и эффективный вариант.
>
> А если там не 1:n? Если там больше двух таблиц?

Тогда надо заполнить несколько таблиц. Не понимаю проблему.

> Если условия на них
> такие, что запрос уже выполняется время, которое надо во внимание
> принимать?

При наличии 1:n-отношениях загрузка несколько таблиц занимает в сети меньше ресурсов (времени перекачки) чем при только одной загрузки с помощбю SQL/JOIN.

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

В чем проблема? При выраженной иерархия лучше использовать несколько запросов чем один, чтобы бытрее загрузить данные.

Peter

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

А>Есть задача: получить из двух таблиц некоторую вырезку. Например:

Use Northwind
Select Employees.EmployeeID, Orders.OrderID from Employees 
        join Orders on Employees.EmployeeID = orders.EmployeeID
    where Employees.LastName = 'Fuller' And Orders.ShipVia = 2

А> ...

Если задача стоит так, как вы решали с помощью SQL, то есть в датасете должна быть только одна таблица, то для этого можно сделать датасет руками или с помощью нового view заточеного под ваш запрос. Если в датасете должно быть 2 таблицы, то в запросе будет 2 селекта. Кажется так.

Здравствуйте, Peter Fleischer, Вы писали:


PF>При наличии 1:n-отношениях загрузка несколько таблиц занимает в сети меньше ресурсов (времени перекачки) чем при только одной загрузки с помощбю SQL/JOIN.

Спорный вопрос... Если в каждой таблице по, допустим, сотням тысяч записей, а в результате JOIN'а отберется по несколько десятков из каждой... По-моему, два SELECT'а (одинаковых, за исключением возвращаемых полей... А что делать?) будут оптимальнее...

Здравствуйте, deekey, Вы писали:


D>Если задача стоит так, как вы решали с помощью SQL, то есть в датасете должна быть только одна таблица, то для этого можно сделать датасет руками или с помощью нового view заточеного под ваш запрос. Если в датасете должно быть 2 таблицы, то в запросе будет 2 селекта. Кажется так.

В датасете хотелось бы иметь две таблицы, но получить их с помощью одного Select'а. Ладно, я понял уже, что это недостижимый идеал. Будем извращаться.

> Здравствуйте, Peter Fleischer, Вы писали:
>
>
> PF>При наличии 1:n-отношениях загрузка несколько таблиц занимает в
> сети меньше ресурсов (времени перекачки) чем при только одной
> загрузки с помощбю SQL/JOIN.
>
> Спорный вопрос... Если в каждой таблице по, допустим, сотням тысяч
> записей, а в результате JOIN'а отберется по несколько десятков из
> каждой... По-моему, два SELECT'а (одинаковых, за исключением
> возвращаемых полей... А что делать?) будут оптимальнее...

Я предплогал, что будут перекачены только нужные записи а не сотни тысяч.

Peter

> Здравствуйте, deekey, Вы писали:
---
> В датасете хотелось бы иметь две таблицы, но получить их с помощью
> одного Select'а. Ладно, я понял уже, что это недостижимый
> идеал. Будем извращаться.

Бери один SQL/JOIN и потом скопируй мастер-часть в отдельную таблицу. Но это требует больше объема перекачки чем отдельными SELECT.

Peter

Здравствуйте, Peter Fleischer, Вы писали:

PF> Я предплогал, что будут перекачены только нужные записи а не сотни тысяч.

Хех... Хорошо бы... Только как эти нужные записи, не выполняя JOIN, отобрать?

> Здравствуйте, Peter Fleischer, Вы писали:
>
> PF> Я предплогал, что будут перекачены только нужные записи а не
> сотни тысяч.
>
> Хех... Хорошо бы... Только как эти нужные записи, не выполняя JOIN,
> отобрать?

Очень просто:

SELECT * FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'

Вариант 1:

SELECT Tab1.* FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'
SELECT Tab2.* FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'

Вариант 2:

SELECT * FROM Tab1 WHERE Tab1.F1 ='x'
SELECT * FROM Tab2 WHERE Tab2.FK IN (SELECT Tab1.ID FROM Tab1 WHERE Tab1.F1 ='x')

Peter

Здравствуйте, Peter Fleischer, Вы писали:

>> Хех... Хорошо бы... Только как эти нужные записи, не выполняя JOIN,
>> отобрать?

PF>Очень просто:

PF>SELECT * FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'
______________________________^Здесь и в последующих примерах, очевидно, Tab2? А потом уж, если брать ближе к жизни, "AND TAB2.F2 = 'Y'"
Допустим, получаем 100 строк.

PF>Вариант 1:

PF>SELECT Tab1.* FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'
PF>SELECT Tab2.* FROM Tab1 INNER JOIN Tab1 ON Tab1.ID = Tab2.FK WHERE Tab1.F1 ='x'

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

PF>Вариант 2:

PF>SELECT * FROM Tab1 WHERE Tab1.F1 ='x'
10.000 записей из 100.000 положим. Уже не нравится

PF>SELECT * FROM Tab2 WHERE Tab2.FK IN (SELECT Tab1.ID FROM Tab1 WHERE Tab1.F1 ='x')

А вот в такой записи есть принцйипиальная разница? Это ж тот же JOIN, но записанный по-другому?

Ладно, понятно все, вроде... Надо делать через вариант 1, мне кажется.

А>Но перед этим я хочу знать, рекомендовано ли какое-либо решение подобной проблемы Microsoft'ом (не нашел ни в MSDN'е, ни в интернете)

Рекомендовано затаскивать данные в разные таблицы и объединять на клиенте при помощи Relation.

Если у тебя в таблицах есть нужные строки и ненужные, фильтруй при помощи where. Даже если это будет лишних пару телодвижений на сервере, так правильнее.


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