T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Ок. В моей практике bulk copy применялся редко. Мало, что могу сказать на этот счет. Но если нужно, то можно реализовать через Microsoft.Data.SqlClient

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Мой опыт 25 лет в этом. Что конкретно вас интересует? LLM может сгенерировать бесконечное множество ответов. Но конкретно этот ответ на мною сформулированный помпт, мною проверен и валидирован и он 100% релевантен вашему вопросу, заданному выше. Вам шашечки или ехать?

По сетевому этикету, попрошу вас не флудить и не писать сюда оффтоп, т.е. нерелевантный исходной теме статьи контент.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Вы меня проверяете или хотите получить ответ на свой вопрос? Меня проверять не надо. Я же не на экзамене и не на собеседовании.

Если вас ваш же вопрос не интересует, то тем более, мне нет смысла тратить свое время на ответ.

И это Gemini 2.0 Flash Light. Я между прочим потратил личные деньги на генерацию ответа для вас. Не много, но спасибо сказать можно. Если оно, конечно, вам нужно. Если нет, то вопрос исчерпан, полагаю.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

BulkCopy - это функционал MSSQL. linq2db - просто посредник, интерфейс, портал. Посредников существует много, суть данной статьи не в этом.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Да, конечно. Области, где T-SQL превосходит C# EF LINQ (и почему):

1. Оптимизация запросов и контроль над планом выполнения:

   • T-SQL: Вы имеете полный контроль над планом выполнения запроса. Вы можете использовать EXPLAIN PLAN (или аналогичные инструменты) для анализа плана, добавлять подсказки (hints) для оптимизатора, переписывать запросы для повышения производительности. Вы можете тонко настраивать индексы, статистику и другие параметры, влияющие на производительность.

   • C# EF LINQ: Вы полагаетесь на преобразование LINQ-выражений в SQL-запросы, выполняемое EF Core. Хотя EF Core хорошо справляется с этим, он не всегда генерирует оптимальные запросы. Вы ограничены в контроле над планом выполнения. Вы можете использовать FromSqlRaw или FromSqlInterpolated для написания сырых SQL-запросов, но это снижает преимущества ORM. Оптимизация запросов требует глубокого понимания SQL Server и того, как EF Core преобразует ваши LINQ-выражения.

2. Сложные вычисления и аналитика:

   • T-SQL: T-SQL предоставляет мощные инструменты для сложных вычислений и аналитики:

     • Оконные функции: OVER, LAG, LEAD, NTILE, RANK, DENSE_RANK и т.д. Позволяют выполнять сложные вычисления на основе наборов строк (например, скользящие средние, ранжирование, расчеты с предыдущими/следующими значениями).

     • Рекурсивные CTE: Незаменимы для работы с иерархическими данными (например, организационные структуры, BOM).

     • PIVOT и UNPIVOT: Упрощают преобразование данных между строчным и столбцовым представлением.

     • GROUPING SETS, CUBE, ROLLUP: Обеспечивают гибкость при агрегации данных.

     • Встроенные функции для работы с датами, строками, XML, JSON: Оптимизированы для работы с данными в базе данных.

   • C# EF LINQ: Вы можете выполнять эти вычисления в C#, но это часто означает:

     • Перенос данных на клиент: Снижает производительность, особенно для больших объемов данных.

     • Сложные LINQ-выражения: Могут быть сложными для написания, чтения и отладки.

     • Меньше контроля над оптимизацией: EF Core может не всегда эффективно преобразовывать сложные LINQ-выражения в SQL.

3. Работа с большими объемами данных:

   • T-SQL: SQL Server оптимизирован для работы с большими объемами данных. Вы можете использовать:

     • Пакетную обработку: BULK INSERT, OPENROWSET для быстрой загрузки данных.

     • Partitioning: Разделение таблиц на разделы для повышения производительности запросов и обслуживания данных.

     • Clustered Columnstore Indexes: Оптимизированы для аналитических запросов к большим объемам данных.

   • C# EF LINQ: Работа с большими объемами данных в EF Core может быть проблематичной:

     • Проблемы с производительностью: Запросы могут выполняться медленно.

     • Необходимость разбиения на страницы: Для обработки больших наборов данных.

     • Потенциальные проблемы с памятью: При загрузке больших объемов данных в память.

4. Безопасность и производительность хранимых процедур:

   • T-SQL: Хранимые процедуры позволяют:

     • Инкапсулировать логику: Упрощает поддержку и повторное использование кода.

     • Повысить безопасность: Предоставлять доступ к данным через хранимые процедуры, ограничивая прямой доступ к таблицам.

     • Улучшить производительность: Хранимые процедуры компилируются и кэшируются, что может повысить производительность.

     • Управлять транзакциями: Обеспечивать целостность данных.

   • C# EF LINQ: Вы можете вызывать хранимые процедуры из EF Core, но:

     • Снижается типизация: Вы теряете преимущества статической типизации при работе с результатами хранимых процедур.

     • Сложность отладки: Отладка хранимых процедур может быть сложнее, чем отладка C# кода.

5. Триггеры и ограничения на уровне базы данных:

   • T-SQL: Триггеры позволяют автоматически выполнять действия при изменении данных. Ограничения (constraints) обеспечивают целостность данных.

   • C# EF LINQ: Вы можете реализовать логику в C#, которая будет выполняться при изменении данных, но это не всегда эффективно и может привести к проблемам с производительностью и целостностью данных.

Примеры сценариев, где T-SQL незаменим:

• Сложные аналитические отчеты: Расчет скользящих средних, ранжирование, сравнение с предыдущими периодами для больших объемов данных.

• Обработка иерархических данных: Построение организационных структур, BOM, маршрутизация данных.

• Оптимизация производительности критичных запросов: Тонкая настройка индексов, переписывание запросов для повышения производительности.

• Загрузка больших объемов данных: Использование BULK INSERT для быстрой загрузки данных.

• Реализация сложной бизнес-логики на уровне базы данных: Триггеры, хранимые процедуры для обеспечения целостности данных и безопасности.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

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

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Условия в логике через CASE или IF прекрасно работают. Можно в функцию инкапсулировать. Зато работает быстро и надежно.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Поменяю функции. Язык очень гибкий.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

По своему, вы конечно правы. Но все же все неоднозначно. На любую проблему может быть как минимум две точки зрения.

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

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

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

Замеры и метрики - не входят в данную тему. Так что чувство вины за собой не испытываю по данному поводу.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Да, я скорее рассуждал именно в контексте отчетов. А так-же каких-то сложных процедур.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Вот пример запроса на t-sql который более нативен природе данных и содержит значительно меньше кода, а код более понятен, чем если это громоздить на C# LINQ... (конечно зависит от разработчика, его опыта и предпочтений. но на t-sql это работает точно быстрее. а в моем случае и разрабатывается).

WITH
    -- Уровень 1: Получение базовых данных о продажах и продуктах
    SalesData AS (
        SELECT
            s.SaleID,
            s.ProductID,
            s.SaleDate,
            s.Quantity,
            p.ProductName,
            p.Category
        FROM
            Sales AS s
        INNER JOIN
            Products AS p ON s.ProductID = p.ProductID
        WHERE
            s.SaleDate >= DATEADD(month, -12, GETDATE()) -- Фильтруем продажи за последние 12 месяцев
    ),

    -- Уровень 2: Расчет выручки по каждой продаже
    SalesWithRevenue AS (
        SELECT
            sd.SaleID,
            sd.ProductID,
            sd.SaleDate,
            sd.Quantity,
            sd.ProductName,
            sd.Category,
            sd.Quantity * (
                SELECT Price
                FROM ProductPrices pp
                WHERE pp.ProductID = sd.ProductID
                AND pp.EffectiveDate <= sd.SaleDate
                ORDER BY pp.EffectiveDate DESC
                FETCH FIRST 1 ROW ONLY
            ) AS Revenue  -- Расчет выручки с учетом динамических цен
        FROM
            SalesData AS sd
    ),

    -- Уровень 3: Агрегация данных по месяцам и категориям
    MonthlyCategoryRevenue AS (
        SELECT
            FORMAT(swr.SaleDate, 'yyyy-MM') AS SaleMonth,
            swr.Category,
            SUM(swr.Revenue) AS MonthlyRevenue,
            COUNT(DISTINCT swr.SaleID) AS NumberOfSales
        FROM
            SalesWithRevenue AS swr
        GROUP BY
            FORMAT(swr.SaleDate, 'yyyy-MM'),
            swr.Category
    ),

    -- Уровень 4: Расчет скользящей средней выручки за 3 месяца
    RollingAverageRevenue AS (
        SELECT
            mcr.SaleMonth,
            mcr.Category,
            mcr.MonthlyRevenue,
            mcr.NumberOfSales,
            AVG(mcr.MonthlyRevenue) OVER (PARTITION BY mcr.Category ORDER BY mcr.SaleMonth ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) AS RollingAverageRevenue  -- Скользящая средняя
        FROM
            MonthlyCategoryRevenue AS mcr
    ),

    -- Уровень 5: Определение лидеров по росту выручки (сравнение с предыдущим месяцем)
    RevenueGrowth AS (
        SELECT
            rar.SaleMonth,
            rar.Category,
            rar.MonthlyRevenue,
            rar.NumberOfSales,
            rar.RollingAverageRevenue,
            LAG(rar.RollingAverageRevenue, 1, 0) OVER (PARTITION BY rar.Category ORDER BY rar.SaleMonth) AS PreviousMonthRollingAverage,
            (rar.RollingAverageRevenue - LAG(rar.RollingAverageRevenue, 1, 0) OVER (PARTITION BY rar.Category ORDER BY rar.SaleMonth)) / LAG(rar.RollingAverageRevenue, 1, 0) OVER (PARTITION BY rar.Category ORDER BY rar.SaleMonth) * 100 AS RevenueGrowthPercentage
        FROM
            RollingAverageRevenue AS rar
    )

-- Финальный SELECT: Вывод лидеров по росту выручки за последний месяц
SELECT
    rg.SaleMonth,
    rg.Category,
    rg.MonthlyRevenue,
    rg.NumberOfSales,
    rg.RollingAverageRevenue,
    rg.RevenueGrowthPercentage
FROM
    RevenueGrowth AS rg
WHERE
    rg.SaleMonth = (SELECT MAX(SaleMonth) FROM RevenueGrowth)  -- Фильтруем по последнему месяцу
ORDER BY
    rg.RevenueGrowthPercentage DESC;

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Что понимать под бизнес - логикой? Если работа производится над данными которые являются формализацией бизнес-процессов, то осмелюсь утверждать, что алгоритмы по работе с такими данными (извлечение, изменение, запись, удаление) - является бизнес-логикой.

Вам привести пример t-sql запроса, который легче реализовать в ядре БД, чем через LINQ? Думаю, что без конкретного кейса и понятного всем контекста, это может выглядеть не достаточно убедительным. Если технически только.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Скажите, где большая ценность сосредоточена? В кодах или в данных?

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

По-моему, это настолько очевидно, то можно было даже ИИ не беспокоить.

Я не знал этого. На счет "беспокоить" ИИ. Чем ИИ хорош, что он может бесконечно отвечать на любые вопросы, даже глупые, не раздражается, не уходит из-за занятости. И отвечает вполне разумно. Можно конечно погуглить, но через ИИ быстрее. Если вопрос критичный - то конечно лучше проверить в разных источниках.

То есть поставить бизнес-логику в зависимость от приложения.

Это тоже неоднозначно. По сути приложение - это кристаллизация бизнес логики. В своем смысле - логика ставится в зависимость от "кристалла". Это так и есть. Опять параллели с дилеммой, что важнее: код или данные. Форма или содержание. А может быть даже: что первичнее - яйцо или курица.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Это не мой ИИ. Странно на ИТ-ресурсе читать такие утверждения, что ИИ что-то превращает в помойку. Мое мнение - что в помойку что-угодно превращает негативное отношение к другим людям. Вы же не высказались по существу темы, а просто вбросили оффтоп. В этом плане, с ИИ гораздо интереснее общаться и полезнее. К сожалению. Но к счастью, есть люди, с которыми общение еще возможно по сути.

Социализм vs Капитализм — когда мифы важнее фактов

Коммунистическая экономическая система, в отличие от капиталистической ("рыночной") отличается централизованным подходом к планированию государственных (и/или глобальных) экономических ресурсов. На основании единого национального/наднационального плана счетов. Это очень сложная вычислительная задача и ее решение за счет бюрократических механизмов посыпалось в 20-м веке. Но концептуально - это намного более оптимальная система с точки зрения национальной экономики. А может быть и глобальной. В 21 веке открывается второй шанс с появлением вычислительных мощностей. Математические модели централизованного гос. плана не так уж плохи. Плоха была их реализация, когда для расчетов использовались люди, подверженные человеческому фактору, в частности - коррумпированности.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

EF прекрасно справляется с предоставлением доступа к инфраструктуре MSSQL. Поэтому ничто не мешает бизнес-логику в той или иной степени распределять на код БД (если "вера позволяет"). Без linq2db.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

В статье не предлагается использовать t-sql в ef. Предлагается смело использовать мощь t-sql (прежде всего CTE, SP, UDF) в MSSQL, а через EF успешно и просто пользоваться этим без громоздкого и низкоэффективного в сложных случаях LINQ и миграций code-first. Как? Об этом статья.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Если взять многоэтапный CTE запрос и попытаться его перенести на LINQ - то становится понятна суть идеи статьи.

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

Спасибо за ваши комментарии и обратную связь.