А кто нибудь писал очень большие приложения на ноде? Например

когда в БД 50-100 таблиц. Что то типа 1С, когда много документов, с согласованием, справочниками разными

не раз было дело.. именно реляционная БД?

да тут не в БД дело, а интересно какую архитектуру API и бэка в целом правильно выбрать

ту, какая известнее/удобнее для исполнителей)

50-100 таблиц это не много

> очень большой > 50-100 таблиц Забавно 🙂 Количество таблиц в твоём понимании отражает количество кода в проекте? Тогда - да, много кто писал Но вероятно в контексте ноды может быть лучшем вариантом разбить монолит на отдельные сервисы. И вместо одной бд с сотней таблиц получить 10 сервисов с десятком таблиц каждый

вот мне интересно как заводят очередной 101 документ? рисуют схему с нуля или организуют какое то наследование, продумывают типовые подходы

ну зависит от потребностей, я без рисований схем всегда создавал, на крайняк ALTER TABLE

Можно любые документы в 3 таблицы засунуть через EAV https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

Количество таблиц говорит об объеме проекта. Вот в 1С Управление Торговлей только документов около 100, а еще больше справочников, регистров, в сумме я думаю около 300 получится. И у каждого объекта есть пара тысяч строк бизнес-логики

Не обязательно. Может быть проект со сложной логикой и в пару десятков таблиц

тогда это небольшой проект, если пара десятков таблиц это не корпоративный уровень а маленький стартап с узким функционалом

Типа какого-нибудь яндекс.такси, например. Небольшой стартап

> с узким функционалом :)

Меня подбешифает факт что TS плохо работает с цифрами и их хранить строками считается нормой. Но наверное люди живут как-то.

а что у яндекс такси ппц какой богатый функционал? По сути 2 функции - подобрать водителю заказы и подобрать пешеходам машину

Там работы на час для специальноста

А если у ООО "рога и копыта" 342 таблицы в бд, это автоматически значит что проект крупный? Даже если у них один заказ в день?

это значит что работают фанаты нормализации. таблица - 3 поля, ключ, foreign key и описание.

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

Но при этом кода в проекте с двумя десятками таблиц может быть кратно больше. Просто потому, что логика работы проекта гораздо более сложная Не может количество таблиц в бд однозначно отражать размер проекта

ну я больше про корпоративные системы, а там как раз может, там нет хитрых алгоритмов и нейросетей, тупо добавляются сущности и фичи для логики с простым кодом

Есть там и хитрые алгоритмы, и мл, и нейросети. Не у всех, и не всем это нужно, но даже в (относительно) простой тематике документооборота сложностей может быть много

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

Это входит в стандартную задачу документооборота Интереснее становится когда надо организовать блокчейн из документов, прогонять документы через анализаторы для автоматической классификации, поиска противоречий и подготовки аннотации - вот тут уже и мл с нейросетями пригодится

Документооборот не сложно писать, количество таблиц не важно, логика не сложная. Сложно автоматизировать большой бизнес, делая аналог sap, с кучей бизнес транзакций.

в том то и дело что документооборот это только одна из десятков фич в нормальной бизнес-системе

Да. В таких потребностях сейчас заметные изменения на рынке. Сейчас с уходом sap глобальный переход на 1с идёт, либо пилят платформу агрегатор как центральный сервис на чем придётся, на той же node, а к ней конектят уже ту же 1с ку и другие микросервисы на разных технологиях. Я почти не встречал проектов, которые с нуля делают сложные бизнес системы. Либо на 1с, либо зоопарк микросервисов с центральным агрегатором.