Хранимая процедура или расчеты через IQueryable?

Question

Это вопрос, основанный на выборе производительности по сравнению с методами проектирования. Если у меня есть метод, который будет выполняться много раз в секунду;

public static IQueryable<IPerson> InRadius(this IQueryable<IPerson> query, Coordinate center, double radius)
{
    return (from u in query
            where CallHeavyMathFormula(u, center, radius)
            select u);
}

Этот метод расширения для IQueryable генерирует SQL, который выполняет некоторые сложные математические вычисления (косинус, синус и т. Д.). Это будет означать, что приложение отправляет 1-2 КБ sql серверу за вызов.

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

Answer 1

Во-первых, в зависимости от используемой базы данных, он может кэшировать планы выполнения и результаты как для хранимых процедур, так и для специальных запросов. Это должно быть основной причиной, по которой нужно идти в коде против хранимой процедуры. Вы также можете использовать функцию .net внутри sql, чтобы сохранить часть условия в виде кода .net (слишком сложно написать условие в виде sql и т. Д.) Тогда вместо того, чтобы нажимать на db слишком часто, я бы попытался кэшировать результаты.

Не является грехом иметь в приложении как хранимые процедуры (в основном для сложных запросов, где SP создаст значительное улучшение), так и специальный код с помощью iqueriable.

Использование средства профилирования SQL также может помочь вам выбрать лучшее решение.

И до тех пор, пока у вас нет перехода на другой БД в плане ближайшего будущего или если это просто «может произойти», игнорируйте это сейчас, рассмотрите возможность сделать это позже как часть необходимого рефакторинга на этом этапе. момент.

Answer 2

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

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

1-2 КБ на вызов базы данных для меня не слишком много.

Я бы не стал рассчитывать тяжелую математику синусов и косинусов. Динамическое БПФ или решение линейной алгебры было бы гораздо более сложным. Ничто из того, что я бы назвал тяжелым, не будет выполняться несколько раз в секунду.

Мне кажется, что вы будете в безопасности, оставив этот расчет на стороне приложения.