LINQ к SQL левое внешнее объединение
Используйте groupby с pd.Grouper:
u = (df.groupby(['computer', pd.Grouper(key='time', freq='4s')])
.sum()
.sort_index(level=1)
.reset_index())
u['time'] = u['time'].dt.second
u
computer time value
0 0 0 5
1 1 0 1
2 2 0 5
3 3 0 6
4 2 4 3
5 3 4 4
Вместо того, чтобы иметь отдельные groupby и resample, вы можете разрешить одному вызову groupby обрабатывать обе группировки на «компьютере». ", и пересчет" время "вместе.
3 ответа
Не совсем - так как каждая "левая" строка в лево-внешнем объединении будет соответствовать 0-n "правильным" строкам (во второй таблице), тогда как Ваш соответствия только 0-1. Чтобы сделать левое внешнее объединение, Вам нужно SelectMany и DefaultIfEmpty, например:
var query = from c in db.Customers
join o in db.Orders
on c.CustomerID equals o.CustomerID into sr
from x in sr.DefaultIfEmpty()
select new {
CustomerID= c.CustomerID, ContactName=c.ContactName,
OrderID = x.OrderID == null ? -1 : x.OrderID};
Заботятся о производительности:
я испытал это, по крайней мере, с [1 122] Ядро EF , различные ответы, данные здесь, могли бы привести к другой производительности. Я знаю, что OP спросил о Linq к SQL, но мне кажется, что те же вопросы происходят также с Ядром EF.
В конкретном случае я должен был обработать, (синтаксически более хороший), предложение Marc Gravell, приведшим к левым соединениям в кресте, применяется - так же к тому, что Mike U описал - , который имел результат, что предполагаемые затраты для этого определенного запроса были в два раза более высокими по сравнению с запросом без перекрестных объединений . Время выполнения сервера отличалось фактором 3 . [1]
решение Marc Gravell привело к запросу без перекрестных объединений.
Контекст: я по существу должен был выполнить два левых соединения на двух таблицах, каждая из которых снова потребовала соединения к другой таблице. Кроме того, там я должен был определить другие где-условия на таблицах, на которые я должен был применить левое соединение. Кроме того, у меня было два внутренних объединения на основной таблице.
затраты оператора Estimated:
- с крестом подайте заявку: 0.2534
- без креста подайте заявку: 0.0991.
время выполнения Сервера в мс (запросы выполнились 10 раз; измеренное использование УСТАНОВИЛО ВРЕМЯ СТАТИСТИКИ НА):
- с крестом подайте заявку: 5, 6, 6, 6, 6, 6, 6, 6, 6, 6
- без креста подайте заявку: 2, 2, 2, 2, 2, 2, 2, 2, 2, 2
(Самое первое выполнение было медленнее для обоих запросов; кажется, что что-то кэшируется.)
размеры Таблицы:
- основная таблица: 87 строк,
- первая таблица для левого соединения: 179 строк; 116-секундная таблица для левого соединения: 7 строк.
Базовая версия EF: 2.2.1.
версия SQL Server: SQL Server MS 2017 - 14... (в Windows 10).
Все соответствующие таблицы имели индексы на первичных ключах только.
Мое заключение: всегда рекомендуется посмотреть на сгенерированный SQL, так как это может действительно отличаться.
<час>[1] Интересно достаточно, при установке 'Клиентской статистики' в Studio управления SQL Server MS на, я видел противоположную тенденцию; а именно, то последнее выполнение решения без креста применяется, занял больше чем 1 с. Я предполагаю, что что-то шло не так, как надо здесь - возможно, с моей установкой.
Public Sub LinqToSqlJoin07()
Dim q = From e In db.Employees _
Group Join o In db.Orders On e Equals o.Employee Into ords = Group _
From o In ords.DefaultIfEmpty _
Select New With {e.FirstName, e.LastName, .Order = o}
ObjectDumper.Write(q) End Sub