> Но зачем все это пихать в sql базу и манипулировать потом нестандартным sql dml'ем?Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой.
Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке.
Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида:
struct Vertex {
name: String,
edge: Vec<Edge*>,
}
struct Edge {
left: *Vertex,
right: *Vertex,
}
не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.
