Это лучше дополнительный запрос или получить все данные и фильтр в клиенте?

Question

У меня есть запрос с EF Core, в который я хотел бы включить свойство и из этого свойства, что это ICollection, я хотел бы отфильтровать, какие данные получить.

Это что-то вроде этого:

myDbContext.MyEntity.Where(x => x.ID == 1).Include(x => x.MyCollection.Where(y => y.isEnabled == true));

Однако я получаю сообщение об ошибке, поскольку невозможно отфильтровать включенные свойства.

На самом деле элементов в коллекции будет немного, около 6 или 7,поэтому я подумал, что мог бы включить все и затем отфильтровать данные в клиенте.

Другой вариант - сначала получить основную сущность, а во втором запросе получить дочерние элементы, которые мне действительно нужны.

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

Но в этом случае, с EF Core, кажется, что я не могу фильтровать в запросе, поэтому я хотел бы знать, что лучше,2 запроса и получают только те данные, которые мне нужны, или один запрос, получающий все данные и фильтрующий позже в клиенте.

Answer 1

Но в этом случае с EF Core кажется, что я не могу фильтровать запрос, поэтому я хотел бы знать, что лучше, 2 запроса и получить только те данные, которые мне нужны, или один запросполучение всех данных и фильтрация позже в клиенте.

Что длиннее?Один длинный кусок шнура или два более коротких фрагмента?

Вы не знаете, потому что я не сказал вам фактическую длину.Вы не знаете, если это строка 1 м против двух нитей 5 см или строка 10 см против двух ниток 8 см.

И ваш вопрос здесь тот же.Лучше делать меньше запросов, чем много, и лучше делать короткие запросы, чем длинные.Когда выбор сделан только по одной из этих метрик (например, более короткий запрос из простого Where в базе данных по сравнению с простым Where в памяти для всех результатов), тогда мы можем сделать звук a priori суждения о том, что может быть более эффективным, и выбирайте соответственно.

Когда у нас есть конкурирующие факторы в игре, мы должны:

1. Решить, будем ли мы вообще заботиться: Если они все еще будут довольно быстрыми в любом случае, о них не стоит беспокоиться;найдите большую рыбу, чтобы жарить.

2. Измерение.

3. Убедитесь, что то, что мы измеряем, реалистично.

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

Когда разница невелика, или если они оба быстры в любом случае (и / или использование настолько редко, что это все еще небольшое дело), ​​а затем просто пойти на то, что проще кодировать и поддерживать.