Что-то я не понимаю поведение построителя запросов... пример:
Есть табличка Clients и подчиненная ей Users (связь OneToMany, Users.ClientID -> Clients.ID)
В результате такое выражение:

вызывает загрузку ВСЕЙ таблицы Users для указанного client.ID. Получаемый запрос от второй строки:


Т.е. загружаются ВСЕ записи, вместо того чтобы выбрать одну через WHERE ClientID = @p0 and ID = @p1
Почему так? В подчиненной таблице может быть тысячи записей, и зачем их грузить все на клиента, если достаточно выбрать одну запросом?

p.s. в реальности поиск в client.Users идет не по ID, но это не меняет сути, и ID использован просто для простоты

SanSYSочему - хз, даже сомневаюсь что вы правы, попробуйте использовать LinqPad

там можно увидеть сгенерированный запрос


Естественно смотрел реально полученные запросы, от чего и тема выросла :)
Народ пишет что это нормальное поведение большинства фреймворков аля LtoS...

SanSYS
но с др. стороны...
1. вы достали клиента
2. у клиента есть незагруженные юзеры
3. ищете юзера у экземпляра клиента
4. список юзеров у клиента - это 1 список, типа 1 объект, и инициализировать одну часть (загружать одного юзера) объекта, было бы нелогично, т.к. список должен быть отсортирован по индексу, потому собственно наверн и загружаются все юзеры
5. зато при поиске следующего юзера не будет запросов :)


Если следовать идее - контексты создавать на короткое время, и как можно быстрее освобождать, то другие Users будут добываться уже в другом контексте, и сл-но опять будет вытаскиваться на клиента лишние записи.

Пример: сущность Project, у неё есть подчиненная табличка Respondents, в которой десятки тысяч записей. И получается что если мне надо выбрать нескольких респов, то я таки не могу использовать удобную запись project.Respondents.Where(r => r....), а вынужден пользовать что-то аля context.Respondents.Where(r => r.ProjectID == pId && r....).
Но чем такая запись отличается за чистого SQL? Почти ничем... получается что есть у нас DataContext, в нем есть куча таблиц, и с ними напрямую и приходится работать, всегда указывая все параметры выборки явно... теряется как-то абстракция, в бизнес-логику пролезают FK/PK ключи и т.д.

Получается что есть sql, чтобы от него абстрагироваться - применяем Linq To Sql, а потом поверх ещё какой-нибудь паттерн аля Repository, и тут наступает нирвана. Но блин, ничего ен мешает выкинуть удобный linq и оставить sql + repository, результат будет тот же, т.к. в бизнес-логике все равно надежнее с ним работать, чтобы иметь полный контроль над вытягиваемыми из базы данными.

Речь про базы с по крайней мере несколькими миллионами записей.

SanSYS
советую написать так:

тогда точно 1 запрос = 1 запись ор нул

[/SRC]это понятно, можно и красивее сделать, например в Client добавить функу, типа:

и тогда будет что надо, один запрос на вытягивания одного юзера
но блин, это всё какие-то танцы с бубном... :)

SanSYSчтож, экзекьютквери вам в помощь :) приятно получать раскрытые ответы

у нас есть1 большой сайт, там юзается линку, собственно - сохраняе 1 датаконтекст на протяжении всего запроса, это оказалось производительнее чем создавать новые, имхо, но если выборки в каждом запросе не накладные, в противном случае - юзаем новые экземпляры

С ExecuteQuery тоже обнаружились проблемы :)
http://www.sql.ru/forum/actualthread.aspx?tid=765340

У меня прям дар, наступать на грабли :)