Здравствуйте, Vladek, Вы писали:

V>Это аргументы в стиле подкладывания рельсы японской пиле. Да мало ли какую страшную картинку можно нарисовать, какое отношение работа с БД имеет к внятной архитектуре? А что, если изменение зарплат сотрудников на выходе имеет не SQL-запрос, а документ на подпись начальнику? А потом подписанный документ с штрих-кодом сканируется и выполняется нужное действие, опять же не через SQL, а запросом в облако к нереляционному хранилищу?
В конце концов в базе данных должны произойти изменения, должен выполниться тот самый апдейт.

Ты пытаешься уменьшить важность проблемы, тип что повышение ЗП нечастое явление и апдейту предшествует много других операций.
Но ты забыл что повышение ЗП было выбрано как пример, можно найти миллионы операций, которые часто выполняются и для них твоя логика "уменьшения проблемы" просто не сработает.
А еще на практике неоднократно видел, такой стиль работы с базой проникает во все части программы, и тормозит вообще все.

V>Да, отполированные знания тонкостей работы какой-то БД важны, но БД — не более, чем деталь реализации.
БД — серьезное архитектурное ограничение. Изменение БД может поменять архитектуру всей системы.
Знаю один курьезный случай, когда группу разработчиков обученных T-SQL отправили писать код для оракла. Казалось бы в чем проблема, синтаксис выучат и нафигачат код, примерно такой же, как во всех приложениях.
Но выяснилось на ходу, что в оракле индексы работают по-другому и честную сериализуемость оракл не поддерживает. Переписали тогда очень много.