Тут все очень тонко, я бы вводил правила работы с такими сущностями только через сервисы\функции реализующие интерфейс управления этой сущностью. Т.е. через код где все эти проверки проработанны и описанны с комментами. В случае если субд не котнроллит referential integrity то это мастхев как по мне. Те субд которые контролят это номарльно, не дадут тебе удалить что-то что лишнее. Да и я бы не удалял в принципе в таких таблицах, а использвал soft delete.

Мне больше смешно когда в пользу ORM говорят про то что она дает возможность легко перейти на другую субд в будущем.

Хотя последние годы я обмазываюсь монгой и вообще забыл про миграции, схемы и т.д. (только индексы накидываю при росте). Для аналитики создаю табличи в кх и туда кидаю все мало мальски важные события в системе. В 90% случаев это покрывало все запросы на отчеты для аналитикиов\маркетологов. Иногда просто отдал ему доступ на кх и не паришся, он сам собирает то что ему нужно

Да, помойка, но узаконенная 😎

Отвечу пунктами:

– Если я работаю над большим сложным проектом, то да, несомненно я хочу сам контроллировать Referential Intergrity в формате описанным тобой, но скорее всего я пришел бы к тому, что написал сам некоторые хелперы on delete / update / insert. А вот если я хочу накидать что-то быстрое и нанять не самых продвинутых разрабов, то использовал бы ORM, которая сама этим займется с возможностью выключить эту фичу (как начнет появляться доход, перепишем)

– Я вот сейчас хотел написать, что не так часто пользуюсь soft delete, потому что он часто мешает, но понял, что если говорить о масштабируемых данных без поддержки реляций, то soft delete очень даже неплохое решение...

– Последний год активно работал с монгой и не люблю ее всеми фибрами души) Схема у тебя все равно есть, просто в коде; миграции все равно будут (хочешь пересчитать / передвинуть какие-то значения), также как и сиды; агрегации в mongo жуть всравнении с SQL и т.д. Но опять же, тут дело вкуса / привычки каждого человека

– Перекидывать данные в кх – крутая тема до момента инвалидации этих данных 😢

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

С постгрей у меня только 1 претензия – нет автоматического шардирования (а я люблю заинсертить тонну говна и не разбираться как это смасштабируется), поэтому начинаю поглядывать на CockroachDB, PlanetScale, YDB и подобное.

Соглы на 100% по первому пункту)

По второму, интересно узнать какие у тебя кейсы встречались с неудобносью soft delete. У меня отчасти это конечно еще старческое, во времена когда мы пилили одну крупную соц. сеть и тогда у нас не было ssd. Фрагментация дисков при частом удалении записей очень страдала и это сказывалось на скорости.

По третьему, дело вкуса это точно. У нас кстати как-то получалось обойтись без крупных миграций, даже на большом проекте с 20k/rpc и коллекциями >30 млн. записей. Работало на нескольких серваках с реплика сетом, даже норм работало с грамотно проставленными индексами) Но мы заранее очень долго и дотошно подходили к архитектуре коллекций и правилами работы с ними. Агрегациями мы не пользуемся, они жуть как не посмотри)

По кх, у нас не бывает инвалидации (если я правильно понял тебя в этом контексте - устаривание данных \ неактуальные данные) т.к. мы пишем исторические события. Т.е. если что-то поменялось то есть запись об изменении чего-то. Что дает так же возможность получать последние по дате актуальные данные или посмотреть историю изменений) При таком положении у нас нет таблиц - отчетов, есть запросы\вьюхи формирующие отчет.

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

Про soft delete, на самом деле, ты говоришь очень правильные вещи, я бы посидел и больше подумал почему старался его обходить, потому что мне стало понятно, что мои старые аргументы уже давно не работают (надо бы почитать на этот счет)

Про монгу, значит, вы реально умейте ее готовить и это круто) У нас тоже где-то 15к/rpc на 500Gb, коллекции по 20-60 млн. и ничего, держит

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

А про события – ну это вообще красота 🎩 У вас что-то типа Event Sourcing?

О, кстати, вопрос: я сам только с Next.js работал и вижу, что в интернетах пишут: "Astro для статических контентных сайтов, а Next.js, для динамических SPA" – только не совсем понимаю как это выражается

Astro же позволяет передавать клиентские компоненты с логикой, также, собственно, как Next.js, чем же тогда он "недостаточен" для SPA?