Магии там нет - учитесь в рекурсивный SELECT и почитайте что-то вменяемое по теории
https://www.amazon.com/Database-Design-Relational-Theory-Normal/dp/1484255399/
https://www.amazon.com/Database-Design-Mere-Mortals-Hands/dp/0321884493/
https://www.amazon.com/Database-Internals-Deep-Distributed-Systems/dp/1492040347/

В графовых мне нравится, что там язык запросов оптимизирован под графы. Грубо говоря, зачем городить что-то на sql, если можно стрелочками указать связи, даже создавать записи на лету. Очень удобно.

И по скорости выполнения сложных запросов графовые базы обходят реляционные, если для такого же запроса требуется много join.

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

Ну 2020 год провёл за дизайном БД, в том числе и графовых, и работал с большими сетапами графовых БД… поверх кассандры.

1) Графовые БД под капотом чаще всего используют колоночные хранилища на LSM-tree с SSTable и наследуют всю ту же боль что и при работе с Cassandra и прочим
2) C любой современной как реляционной так и нереляционной БД можно сделать графовую - реализовав соответствующие интерфейсы под OpenJanus (https://janusgraph.org/) и удостоверищись в возможности вменяемого индексирования и решения проблемы DataLocality.
3) Обычно Janus оборачивают вокруг BigTable и в принципе это может работать… и даже может быть вполне актуально для некоторых, очень редких, случаев. А для всех остальных 98% - надо просто научиться в рекурсивный SQL SELECT. Но тут есть момент что даже монга становится SQL БД с помощью Apache Calcite… и да, это реляционная БД, о чём мало кто вообще догадывается (оффтопик короч - пригорело).
4) Не так страшна графовая БД как проблема Data Locality в больших масштабах - даже Intel’овским SSD’шкам не хватает IOPS’ов что бы правильно менеджить слияние и разделение страниц в журнале при Compaction’e. LSM-tree там для этого тоже специальный… т.к. надо учитывать adjacent vertices при дампе журнала для Data Locality.
5) По этому в дизайне хранилищ для графовых БД есть определённый, дополнительный Compaction Overhead, и стратегии очень сильно отличаются от того что есть в ScyllaDB и в Cassandra… ну и накладные расходы на любую запись растут экспоненциально с глубиной вашего графа \o/

tldr; графовые БД могут быть только AP и только с большим IO Amplification на запись, если основаны на колоночных БД иди соответствующих структурах данных (LSM-tree).
Если это графовые БД поверх реляционных БД - ведут себя точно так же как любой рекурсивный SELECT.

p.s. Arango построена на RocksDB (колоночный LSM-tree) и каких либо вменяемых стратегий для Compaction’a там нет, про repair не знаю - но вроде пока вообще не завезли.

Ну или еще один вариант: вынимать все данные из реляционной БД в оперативку в графовую структуру и самому строить индексы и писать обход. Если данные не содержат полей переменной длины (а это почти всегда так, все данные переменной длины можно хранить в таблицах рядом), то все записи имеют одинаковую длину и их очень удобно разместить в шаренной памяти (memory mapped files) и доступаться из разных потоков или процессов. Еще проще, когда графы редко меняются, потому, что собирать мусор в такой структуре - это отдельная боль. А если граф перестраивается 1 раз в день или раз в несколько часов, то можно не собирать мусор, а просто готовить его в отдельном сервисе и подгружать целиком иногда. В общем, тут нет готовых решений и для каждого случая и его особенностей нужно собирать что-то уникальное. Пока так.

А с точки зрения безопасности хранения данных тут все ок с таким подходом ?

Народ что думаете про стек TypeScript + Express + InversifyJS, вроде неплохая конкуренция тому же NestJS. Может кто работает с этим стеком, какие нибудь может дополнительные модули хорошие знаете к этому стеку ?

Народ что думаете про стек TypeScript + Express + InversifyJS, вроде неплохая конкуренция тому же NestJS. Может кто работает с этим стеком, какие нибудь может дополнительные модули хорошие знаете к этому стеку ?

Народ что думаете про стек TypeScript + Express + InversifyJS, вроде неплохая конкуренция тому же NestJS. Может кто работает с этим стеком, какие нибудь может дополнительные модули хорошие знаете к этому стеку ?

Но в asp.net тоже же есть мидлвары, там они тоже антипаттерн и плохие?

Но в asp.net тоже же есть мидлвары, там они тоже антипаттерн и плохие?

Все гонение на мидлвары в контексте этого чата сводится к гонению сугубо на мидлвары экспресса

Все гонение на мидлвары в контексте этого чата сводится к гонению сугубо на мидлвары экспресса

Народ что думаете про стек TypeScript + Express + InversifyJS, вроде неплохая конкуренция тому же NestJS. Может кто работает с этим стеком, какие нибудь может дополнительные модули хорошие знаете к этому стеку ?