Linq to Sql: выберите отдельные строки, игнорируя указанные столбцы

Question

Если у меня есть запрос / результаты, установленные следующим образом ...

from t1 in table1
join t2 in table2 on t1.ID equals t2.ID
join t3 in table3 on t2.ID equals t3.ID
select new MyClass()
{
   ID = t1.ID,
   Name = t2.Name,
   Rank = t2.Rank,
   City = t3.City
}

ID | Name | City | Rank
01 | Test | Fake | 876
01 | Test | Fake | 755
02 | Blah | Fake | 765

Выполнение .Distinct () вернет все 3 записи, но что если я захочу первую и третью записи и нене хотите удалить какие-либо столбцы из моего набора результатов?Есть ли способ указать столбцы, которые будут игнорироваться при выполнении отдельного, или явно включить в отдельном, чтобы я мог сделать что-то вроде этого ...

// pseudo code
.Distinct(o => o.Name.FirstOrDefault())

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

Answer 1

Нет, вы не можете указать проекцию, по которой можно определить равенство для Distinct. (У меня есть методы расширения, чтобы сделать это для LINQ to Objects, но это другой вопрос.)

Я предлагаю вам использовать GroupBy, возможно, в сочетании с First:

var query = from t1 in table1
            join t2 in table2 on t1.ID equals t2.ID
            join t3 in table3 on t2.ID equals t3.ID
            select new { t1.ID, t2.Name, t2.Rank, t3.City } into tuple
            group tuple by new { tuple.ID, tuple.Name, tuple.City } into grouping
            let first = grouping.First() // For convenience
            select new MyClass
            {
                ID = first.ID, City = first.City,
                Name = first.Name, Rank = first.Rank
            };

Обратите внимание, что результаты этого могут быть не детерминированными - вы берете первый элемент каждой группы, игнорируя ранг, - поэтому вы можете получить запись с рангом 876 или вы можете получить запись с рангом 755. .

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