Здравствуйте, amironov79, Вы писали:
A>Использовать их в clr stored procedures.
Теоретически — ничто не мешает. Там же примерно то же, что и в оракле — доступ к самой базе через специальную строку подключения; остальная часть вроде бы та же, что и в обычном коде.
Меня больше беспокоить как грамотно завернуть то, что построено при помощи linq2sql в SqlPipe.
Ну, или как оформить TVF на основе linq2db.

A>Я никогда не поверю, что использование хранимок позволит сократить количество серверов в 4 раза.
Всякое бывает. Бывает, что ничего не меняется, а бывает, что раджакумаровский код на модной жаве, который вытаскивает в апп.сервер полбазы на каждый чих, требует четырёх железок под ферму апп-сервера плюс удвоенное железо для базы, а нормальный код, который обрабатывает данные там, где они лежат, обходится одним апп-сервером плюс один сервер БД.
A>Проблема там будет в чем-то другом. А корпоративный сервер он уже есть, куплен, персонал знает как его обслуживать, админы на mssql криво смотрят.
Вот это вот иллюзия. Я ж говорю — сам всю жизнь так думал, а потом посмотрел, как в реальности заказчики говорят "админы — на зарплате. Либо выучат, либо заменим".
Кого там волнует мнение специалиста с зарплатой в $3000, когда обсуждается вопрос "миграции в клауд" со стоимостью под $200k, плюс TCO в пару десятков килобаксов в месяц.
Но, повторюсь — всякое бывает. Хороший специалист должен при обсуждении таких вопросов говорить не "логика в базе — это ужас-ужас", и не "ой, у вас же уже есть сервер на оракле", а что-типа "ну ок, вот это вам будет стоить X сейчас, но экономить Y в месяц". Ну, либо наоборот — сэкономите X сейчас, а потом заплатите Y, но уже ежемесячно". Или "давайте так взлетим, а по мере роста нагрузки я знаю, как перетащить IO/bound в базу надёжным способом, CPU-bound мы запустим на ферме в качестве фоновой работы, а Network-bound мы зарулим при помощи кэширования на reverse-proxy. Не беспокойтесь, к моменту, когда вам это понадобится, вы сможете бросать в меня деньгами".

A>Ничего не понял. Так завязываемся на mssql или postgres?
Завязываемся на что-то одно, вместо иллюзии "щас мы сделаем приложение, которое будет работать на любой платформе и СУБД по выбору заказчика".

Или вот ещё смешной факт: один из модулей, которыми я занимаюсь, требует свою собственную реляционную базу. Начиналось всё с того самого sqlite, и табличек (guid id, varchar(max) jsondata).
Ну, это когда у всех кастомеров всех реселлеров всех партнёров вместе взятых, было на всех 2 (два) конечных пользователя, работало нормально.

Постепенно sqlite устраивать перестал, зато схема более-менее стабилизировалась.

Переписали это дело на mssql. Миграция базы самого большого партнёра (~50000 пользователей) заняла, емнип, 40 секунд.

Но дело не в этом. Дело в том, что мы как-то стеснялись внезапно поднимать требования в апдейте — типа вчера всё работало бесплатно, а сегодня вынь да полож настоящий MS SQL.
Ок, запилили в инсталляцию по умолчанию localDB — он бесплатный, и к ресурсам непрожорлив.
В реальности, кстати, на полумиллионе пользователей наша штука нагрузки на СУБД практически не создаёт. Там банальные данные типа лицензии/подписки/пользователи, никакой там новомодной бигдаты или машин-лёрнинга.
Так вот: партнёры потихонечку начали приходить к нам с вопросами типа "а давайте мы это как-то перевезём на настоящие большие SQL Server-а".
Ну, мы-то что: там файл скопировать да приаттачить; перевозите!
А они такие: "а вам точно надо SQL Server Express? Можно мы это на Enterprise запустим?"

Ну, то есть нет такой проблемы у них, как поставить пару машин с SQL Server. И стоимость Enterprise лицензии их ничуть не пугает.
И да — это всё те же люди, которые эксплуатируют основную платформу, к которой мы — плагин, на жаве/постгре/линухе. То есть это не так, что у них там стоял единственный корпоративный MS SQL, купленный ещё на инвестиции первого раунда в 2001, и они хотят все приложения туда перевезти.