Производительность: навигационная опора. vs sql

Question

У нас есть class Project со многими Sprints.

Project имеет ICollection<Sprints>. Я хочу выбрать и разделить их на Sprints и вернуться к пользователю из веб-приложения.

Я могу выбрать этот путь: project.Sprints.Skip(...).Take(...) или
таким образомsprints.Where(x=>x.ProjectId == some_projectId).Skip(...).Take(...).

Я хочу понять разницу в производительности между выбором и разбиением на страницы ICollection<T> в качестве свойства навигации и как IQueryable.

первого путь я думаю, что буду не очень хорошо besause всех Sprints повторяются в памяти второго пути может быть медленнее, если есть много-много Sprints на столе (а также она выглядит менее очевидно).

Но как вы думаете?

P.S. Я использую сущность framework 6.0.1 codefirst. Спасибо за ваше время!

Answer 1

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

project.Sprints.Skip(...).Take(...) 

Итак, здесь все спринты загружается в одном запросе, и нумерация страниц будут происходить в памяти. На следующих страницах будет запрашиваться коллекция спринтов в памяти, в которой выполняется проект. База данных больше не пострадает. Но с вашим вторым подходом

sprints.Where(x => x.ProjectId == some_projectId).Skip(...).Take(...) 

пагинация будет происходить на стороне сервера, и вы ударите БД При каждом при загрузке следующей страницы.

Какой подход выбрать, зависит от общего количества спринтов, количества данных, которые необходимо загрузить, и спринтов на страницу. Также это зависит от типа используемого вами приложения. Если это веб-приложение, и вы не можете хранить объект project между запросами, тогда ваш выбор на стороне сайта (вторая опция). Если ваш Sprint - это легкий объект, и количество этих объектов невелико, тогда загрузка сразу становится понятной. Нет решения, которое бы соответствовало всем случаям.