холиворно)

1. В любом серьезном приложении есть разделение слоя доступа к данным и слоя бизес-логики. Если код структурирован, то переписать нужно будет только слой доступа к данным, что всегда не более 20% кода. У меня об этом во многих лекциях есть подробнее.
2. Проблема свопа СУБД на порядок проще проблемы свопа ORM, т.к. они то и стимулируют размазывать доступ по логике.
3. Смена СУБД это свехестественный случай для крупных проектов. Все крупное крепко сидит на оптимизации и фичах конкретной СУБД

Ну меня вот довольно крупный проект. Самой аппке лет 7 наверное уже, итам наворечно всякого ( 😩). Юзалась mssql + win server ( да, да, сервера на винде, о боже! ). И, больше как вопрос антикризисной меры ( win server - надо не хило так башлять за лицуху, Mssql Тоже ) стал вопрос перехода на pgsql

Код конечно разделен, и всё такое. Но менять всё равно огромное количество. И некоторые вещи так просто, поиском по проекту, на заменишь. Вот как раз таки с ф-я БД меньше всего проблем было, т.к. почти всегда есть аналог, нашел аналог, поменял по проекту.
А одна из самых больших болей, это, например были top -> limit т.к. они пишуться в разных частях проека

По поводу свопа ОРМ, не пробовал.

Т.е.  к чему я все это написал
1) Разделение было. При это всё операции с БД были вынесены отдельно, и доступ к ним был по паттерну репозиторий
2) -, не меняли
3) Крепко сидим на фичах, крупный проект, тем не менее смена необходима

И вот тут начинаеться боль, когда господа фигарят инлайны SQL вместо взаимодействия через сущности / queryBuilder -ы

Хз в чем проблема, но в свое время спокойно где-то недели за 2 спокойно мигрировали с мс на постгрес. Было это лет 5 назад, но сомневаюсь что в мс-е сделали что-то новое, чего нет в постгресе.

Isnull -> colasce, dateTypes, top -> limit,  WHERE [ USER_ID ] IN ( поддержка скобок, в пгскол нет ),  HASH JOIN -> таких вещей в pgsql нет, info_company.name + ' ' + info_companytype.name  конкатинация, которой нет pgsql, newid() нет в pgsql, 'CURRENT_TIMESTAMP' - Тоже нет, DATEDIFF и DATEADD -> этих функций в pg sql нет, В pgsql данные хранить через точку ( т.е. к примеру 70.98 ) для типа money,

И правда

в чем же проблема

вообще легачйше перейти

синтаксис же одинаков, чё это я

Это кстати, только то, что я вспомнил. Там гораздо больше

Ну такой хоба

и за 2 недели весь код за 7 лет переписал

изейше

Тоже не вижу проблем, согласен

Чёт я херню сказал

Только не нападайте сразу ссылками на тс

Всем доброй ночи,

export class MetaStorageService {

  constructor(public metaModel: MetaModel) {
  }

  public async createItem(metadata: IJsonMetaModel) {
    return this.metaModel.create(metadata);
  }
}

ребзи обьясните пожалуйста, как с помощью декоратора проинициализировать класс в конструкторе другого класса, да и вообще как это должно работать, а то не вьезжаю)

может кто шарит, да что посоветует

Для тих в кого залишились питання про використання ORM/Query builder/SQL - https://blog.logrocket.com/why-you-should-avoid-orms-with-examples-in-node-js-e0baab73fa5

Current timestamp есть, datediff тоже есть аналоги. Вместо nextid есть sequence. На счет данных через точку - все зависит от выбранной локали бд, выбераете нужную и хоть римскимы цифрами записывайте.
Если оно потом в коде оно вызывается через жопу, в лучших традициях вордпреса, то понятно, что нормально не мигрируешь.