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

V>Это аргументы в стиле подкладывания рельсы японской пиле.
Да нет, это результаты многолетнего негативного опыта. Когда пять лет трахаешься вот с такой вот реальностью, и уже думаешь что другого выхода и нет, и что 70% роллбэков из-за conflicting change — это нормально. Или что апгрейд с одной версии на другую так и должен идти 30 часов, "а что ж вы хотели — там данных два гигабайта!".
Потом после волшебных пенделей выясняется, что тот же самый апгрейд можно написать в виде пары sql-стейтментов, и он пройдёт на тех же данных за 10 минут.
И вот когда выясняется, что можно писать вот такие эффективные батчи, и при этом не надо отказываться от логики на нормальном современном ЯП, то наступает прямо-таки эйфория.

V> Да мало ли какую страшную картинку можно нарисовать, какое отношение работа с БД имеет к внятной архитектуре?
Прямое. Если у вас архитектура построена на lazy load и change tracking, то ваше приложение — гарантированный тормоз.

V>А что, если изменение зарплат сотрудников на выходе имеет не SQL-запрос, а документ на подпись начальнику?
Главное, чтобы для формирования этого документа не надо было просасывать всю базу в память клиента по тонкому каналу в открытой транзакции.
V>А потом подписанный документ с штрих-кодом сканируется и выполняется нужное действие, опять же не через SQL, а запросом в облако к нереляционному хранилищу?
А, ну вот типичный случай продажи нереляционного хранилища тем, кто так и не научился работать с реляционным хранилищем.
Потому что если после сканирования документа мы опять начинаем грузить в память список сотрудников, потом lazy load на их контракты, и потом опять 200 отдельных update стейтментов в реляционке — это умрёт.

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