CalabongaВопрос такой. На сколько оправдано использование в SQL-триггеров при подходе CodeFirst (EntityFramework Core)
, при наличие вариантов, которые исключают какое-либо вмешательство в SQL сервер?

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

CalabongaТак-то оно понятно, но интересует конкретный вопрос относительно миграции. Мешает или способствует?

Не то, чтобы мешают. Но не способствуют, это точно.

skyANAТут триггер помогает.

Слишком частный случай, а ТС пока не озвучил свои варианты использования.

CalabongaДавайте я приведу конкретный пример, а за одно может чего посоветуете. Предположим, что у меня есть Computed Description свойство, мне надо хранить в нем, $"{Name} will pay you {Amount} of {CurrencyName}". При изменении в БД любого из свойств задействованных в выражении, хочется иметь "свежую" версию в свойстве Description.

Какие будут предложения?

Делать это в рамках приложения. Почему? Во-первых, сегодня вам нужен {Name}, который доступен из полей записи, а завтра нужно туда добавлять, допустим, имя текущего пользователя, который из триггера будет недоступен. Во-вторых, триггеры тяжело протестировать. В-третьих, вам может быть нужно одно поведение в одном окружении, и другое в другом (dev, staging, production...).

Calabonga,

На EF ваше Computed Description может быть легко реализовано с помощью свойства, но лучше, если это будет выполняться на уровне репозитория.

Calabonga,

Опять же. Это всё верно до тех пор, пока верно то, что с базой данных работает только приложение, и никто ручками в базу не лезет. Если это так, то мне тут посоветовать что-то трудно. Триггеры, конечно выглядят как решение, но по личному опыту, это не так.

CalabongaВ том-то и дело, и можно обойтись без триггера. Пока работает одно приложение (или несколько приложений), но работают они по одним правилам, то есть везде используется одна и та же функция формирования Description, то это всё работает. Но как только "ручками", кто-то править в БД будет, то триггер отработает, а без него Description будет "сломан"

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