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

G>Ну так проблема версий сервера везде существует. Разве не может получится разных версий API и клиентов? Запросто... В БД вы просто делаете таблицу с текущим номером версии схемы и остальные приложения в эту таблицу смотрят. Делов то...
Проблема не в этом, а в том, что логика в каждом из приложений реализована немножко по-другому. В одном округляется до 2х знаков после запятой, а в другом — до 4х.
G>В случае с сервером с АPI используется аналогичный подход, так что это не то чем уж так разительно подходы отличаются.
Нет, в случае с сервером нельзя забыть "посмотреть в таблицу", потому что версия API уезжает в сервер в обязательном порядке в составе URL.
И даже если вы первую версию АПИ выпустили не подумав про версионирование, то всегда можете положить новый API "рядом" с существующим.

G>DML — нужно запрещать... У вас ведь с App сервером тоже никто контракт внезапно поменять не может. Добавить поле в DTO IsDeleted?
А при чём тут DTO? Мы добавили в схему поле isDeleted, и подпилили код единственного апп-сервера так, чтобы при попытке прочитать такой ресурс получалось 410 Gone, а не данные.
Если внутри апп-сервер устроен нормально (например, вместо чистого sql использует linq), то мы фильтрацию по isDeleted = 0 ставим в единственном месте, которое отвечает за возврать IQueryable<MyEntity> MyEntities. И имеем желаемый накал.

G>Зато есть преимущества, которые никто больше не может перекрыть. Это скорость.
Скорость чего? И по сравнению с чем? Скорость исполнения? Я вас разочарую — ХП исполняется настолько же быстро, сколько и эквивалентный ей SQL батч.
Скорость написания — в разы хуже, потому что язык хреновый. С# по скорости написания корректного кода уделывает любой диалект SQL.
G>И огромная куча функционала под капотом. Мне, например, нравится пример с коллекцией в памяти, которую куча потоков модифицирует в памяти. Как организоывать блокировки? Для каждой строчки read-write lock, а блокировки на диапозоны, а что насчет эскалации блокировок. В SQL Server этот код уже написан, отлажен и работает максимально эффективно. Если вы будете делать что-то аналогичное, то либо потратите кучу времени и напишите кучу кода, либо получите неэффективное решение.
Если честно, то это плохой пример. Для коллекции в памяти иметь словарик rw-локов безо всякой иерархии окажется на несколько порядков эффективнее SQL Server. Просто потому, что он упирается в IOPS диска, а коллекция в памяти — в ширину шины.

Но дело не в этом, а в том, что никто не предлагает отказаться от SQL Server. Просто хранимки в нём для бизнес-логики не нужны. Бизнес-логика пусть будет в сервере приложений, который должен отправлять в сервер нужные нам батчи. Вместо хранимки на 50 килобайт с кучей ветвлений и corner cases у нас будут уезжать 5 килобайт стейтментов, которые делают то же самое.

G>В случае с SQL Server у вас данные в едином месте и управляются единым кодом — там все максимально эффективно, нет лишних сериализаций, переливаний из сущностей в DTO и т.п.
Вообще-то, максимально эффективно SQL Server работает только в рамках стейтментов. В рамках ХП есть много типичных приёмов для просада производительности.
К примеру, т.к. в SQL нет способа, например, передать "стейтмент" как аргумент метода, то для обобщения кода, который должен работать с разными источниками данных, обычно предварительно сливают промежуточные данные во временную таблицу, чтобы потом над ней уже выполнить общую часть алгоритма. Это второй (после курсоров) способ убить производительность сервера на корню. В linq таких ограничений нету, и мы можем на ходу генерировать нужные нам стейтменты. Это позволяет сочетать выразительную мощь современного языка программирования общего назначения с вычислительной эффективностью сиквельного оптимизатора запросов. Итоговая производительность будет лучше, чем у чистых хранимок.