Каскадное удаление EF Core для повышения скорости?

Ok. Немного сложно понять, почему это медленно. Насколько велика структура данных и т. д.

Первое, что бросается мне в глаза, когда я смотрю на приведенный выше код, это следующее:

public static async Task ForceDelete(int ID, ProductContext context)
{
    // wrap the recursion in a save so that it only happens once
    await ForceDeleteNoSave(ID, context);
    await context.SaveChangesAsync();
}

Этот метод вызывается рекурсивно, но каждый раз, когда вы закончите работу с кучей дочерних элементов, он будет вызывать context.SaveChagesAsync(). Это означает, что при запуске кода вы получите несколько сохранений и несколько обращений к базе данных.

Это похоже на анти-шаблон, потому что если ваша программа падает на полпути, она уже удалила часть дочерних элементов.

Вместо этого есть InitForceDelete(), который в конце концов вызовет context.SaveChangesAsync(), так что все это делается за одну операцию.

Что-то вроде этого:

public static async Task InitForceDelete(int ID, ProductContext context)
{
    // wrap the recursion in a save so that it only happens once
    await ForceDeleteNoSave(ID, context);
    await context.SaveChangesAsync();
}

private static async Task ForceDeleteNoSave(int ID, ProductContext context)
{
    var pd = await context.ProductDefinitions
                         .AsNoTracking()
                         .Include(x => x.ProductDefinitions)
                         .SingleAsync(x => x.ID == ID);

    if (pd.ProductDefinitions != null && pd.ProductDefinitions.Count != 0)
    {
        var childIDs = pd.ProductDefinitions.Select(x => x.ID).ToList();

        // delete the children recursively
        foreach (var child in childIDs)
        {
            await ForceDeleteNoSave(child, context);
        }
    }
    var supplier = await context.Suppliers.FindAsync(pd.SupplierID);
    supplier.Edited = true;

    // reload with tracking
    pd = await context.ProductDefinitions.FirstOrDefaultAsync(x => x.ID == ID);
    context.ProductDefinitions.Remove(pd);
}

Теперь, во-вторых, вы должны попытаться проверить sql, который выполняется на вашем SQL-сервере. Вы должны быть в состоянии найти планы выполнения, запускаемые вашими операторами LINQ, и посмотреть, полностью ли сумасшедший SQL. Возможно, ваш код выполняет один вызов за ProductDefinition, что делает его очень медленным.

Извините, я не могу быть более точным, но из представленного вами кода трудно дать прямые указатели, за исключением вашего постоянного вызова context.SaveChagesAsync().

К сожалению, это самореферентное отношение, и каскадное удаление нельзя использовать из-за проблемы «множественных каскадных путей» - ограничения базы данных SqlServer (и, возможно, другой) (у Oracle нет такой проблемы).

Лучший способ обработки баз данных, которые не поддерживают «множественные каскадные пути», — использовать триггер базы данных («вместо удаления»).

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

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

Один из способов реализовать это — начать с запроса с применением начального фильтра, а затем использовать SelectMany для получения следующего уровня (каждый SelectMany добавляет соединение к предыдущему запросу). Процесс завершается, когда запрос не возвращает данные:

public static async Task ForceDelete(int ID, ProductContext context)
{
    var items = new List<ProductDefinition>();

    // Collect the items by level    
    var query = context.ProductDefinitions.Where(e => e.ID == ID);
    while (true)
    {
        var nextLevel = await query
            .Include(e => e.Supplier)
            .ToListAsync();
        if (nextLevel.Count == 0) break;
        items.AddRange(nextLevel);
        query = query.SelectMany(e => e.ProductDefinitions);
    }

    foreach (var item in items)
        item.Supplier.Edited = true;

    context.RemoveRange(items);

    await context.SaveChangesAsync();
}

Обратите внимание, что выполняемые запросы загружают соответствующие Supplier, чтобы их можно было легко обновить.

После того, как предметы собраны, они просто помечаются для удаления с помощью метода RemoveRange. Порядок не имеет значения, поскольку EF Core в любом случае применит команды в соответствии с порядком зависимостей.

Другой способ собрать предметы — использовать ID с предыдущего уровня в качестве фильтра (SQL IN):

// Collect the items by level    
Expression<Func<ProductDefinition, bool>> filter = e => e.ID == ID;
while (true)
{
    var nextLevel = await context.ProductDefinitions
        .Include(e => e.Supplier)
        .Where(filter)
        .ToListAsync();
    if (nextLevel.Count == 0) break;
    items.AddRange(nextLevel);
    var parentIds = nextLevel.Select(e => e.ID);
    filter = e => parentIds.Contains(e.ParentProductDefinitionId.Value);
}

Мне больше нравится прежний. Недостатком является то, что EF Core создает огромные псевдонимы имен таблиц, а также может столкнуться с некоторым ограничением количества соединений SQL в случае большой глубины. Последний не имеет ограничений по глубине, но может иметь проблемы с большим пунктом IN. Вы должны проверить, какой из них больше подходит для вашего случая.