Иван FXS,

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

Hive:
regr_r2()
regr_slope()
regr_intercept()
sum()
count()
avg()
variance()
stddev_pop()

T-SQL
AVG()
SUM()
COUNT()
VAR()
STDEV()

DAX
COUNT( )
AVERAGE( )
STDEV.P( )
VAR.P( )
SUM( )


MDX (в MDX так-же есть поддержка VBA функций)
LINREGINTERCEPT()
CORRELATION()
COVARIANCE()
LINREGSLOPE()
AVG()
...COUNT
LINREGR2()
STDDEV()
SUM()
VAR()


Кроме всего многие базы данных поддерживают интеграцию с внешними библиотеками а так-же родные процедуры работы с ML компонентами (например R или Python )..

Иван FXS,

Чуть чаем не подавился.. мы точно об одной регрессии говорим?
Или в школах какой-то альтернативный математический прогресс пошел?
Насколько я помню именно наличие этих функций является вполне достаточным
условием для нахождения коэффициентов простой линейной регрессии,
(кроме стандартных/основных {арифметических} алгебраических операций:
сложения, вычитания, умножения и деления, и можно чисто с бюрократической
точки зрения добавить операции со степенями и функцию power())

для множественной (многофакторной) немного замороченнее, но тоже вычисляемо

был вопрос - можно-ли.. соответственно дан ответ: можно, и показано направление,
причём на HIVE SQL и некоторых др. диалектах есть готовые функции

но при наличии специально под эти задачи заточенных инструментов вполне
интегрируемых в SQL напрашивается другой не заданный вопрос:
нужно-ли (натягивать сову на глобус, или лезть на кактус)?

Есть же библиотеки оптимизированные на векторную/линейную алгебру, GPU,
расширенные инструкции, дополнительные регистры, параллельность,
многопоточность по всем ядрам и CPU, даже на кластерах через тот-же Spark например..
одни MKL/BLAS + AVX512 чего только стоят по производительности на задачах этого класса,

Python или R в руки и вперёд, уже довольно давно принятый в корпоративном мире стандарт.

но если сильно хочется то напр. на T-SQL набросать можно что-то такое:
(заметь: именно sum/count/avg/var)



С MySQL тоже схожая ситуация как и с MSSQL,

в PostgreSQL и Oracle как и в HIVE ещё есть готовые
regr_intercept()/regr_slope()/regr_r2() ,
плюс дополнительные суммы квадратов, ковариации, корреляции и т.д.

Иван FXS,

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

теперь собственно к ответу на тему по множественной:
для частных случаев где n в пределах малых чисел (даже скорее цифр: 2,3...) - тоже вполне можно жестко прописать
и на SQL, для общей формы где n = произвольное - уже надо писать более замороченную логику генерации выражений
под вычисления с использованием циклов/рекурсий, промежуточных таблиц через динамический SQL,
что потребует намного больших трудозатрат, появятся проблемы с отловом ошибок и обслуживанием
так-же и появятся претензии к производительности (особенно большая чуствительность с ростом n чем при увеличении кол-ва строк)

(не отвечая на не заданный вопрос "нужно-ли это" с учётом наличия более оптимальных средств/языков
{процедурно/объектного программирования с нужным набором функций}
специально предназначенных для таких типов задач)

Иван FXS,

Это не невозможно, очень даже возможно, это попросту непрактично,
поэтому и была череда намёков про сову на глобус .. кактус.