|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Доброго времени, уважаемые форумчане! Нужен совет, какое решение лучше выбрать для хранения связей между сущностями. В общем, ситуация следующая. Имеются сущности "Каталог" и "Запись каталога". Каталогов может быть множество и они могут быть связаны между собой определенным типом связи (наследование, ассоциация, композиция, агрегация). Тип связи определяет характер работы с зависимыми сущностями, плюс для разных типов может задаваться своя бизнес-логика. Каждая запись каталога может ссылаться на другую запись другого каталога. Задача состоит в том, что достаточно часто нужно найти все зависимости для записи каталога, причем в обе стороны - все записи, на которые ссылается данная запись, и все записи, которые ссылаются на данную. Сами сущности хранятся в PostgreSQL, но для решения вышеприведенной задачи хотелось бы выбрать другое хранилище, так как на SQL это довольно трудно реализовать, да и в плане производительности наверняка будет плохо. По-моему, граф как раз подходящая структура для хранения различного рода связей. Ну и тут возникает вопрос, что лучше выбрать для хранения графа связей, в первую очередь в плане производительности, RDF-хранилище (Apache Jena) или графовые БД (Neo4J)? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 16:54 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Big Cheeseно для решения вышеприведенной задачи хотелось бы выбрать другое хранилище, так как на SQL это довольно трудно реализовать, да и в плане производительности наверняка будет плохо. Если требуется найти только прямые ссылки, то это тривиальный запрос. Если полное дерево - чуть более сложный рекурсивный CTE. Производительность - как у обычного индексного запроса, то есть мгновенно. Но раз Вы PostgreSQL не знаете, то для решения задачи лучше поискать что-то более знакомое. Если таковое есть, конечно. PS: А если база в PostgreSQL уже используется и это не новый проект, то лучше Вам с него уйти и не занимать чужое рабочее место. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 18:27 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Спасибо Вам за сообщение! Dimitry SibiryakovЕсли полное дерево - чуть более сложный рекурсивный CTE. Производительность - как у обычного индексного запроса, то есть мгновенно. Откуда такая уверенность? Dimitry SibiryakovА если база в PostgreSQL уже используется и это не новый проект, то лучше Вам с него уйти и не занимать чужое рабочее место Dimitry, кто Вы такой, чтобы давать мне подобные советы? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 20:03 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Big CheeseОткуда такая уверенность? Из личного опыта. Big Cheeseкто Вы такой, чтобы давать мне подобные советы? Опытный разработчик БД и приложений к ним. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 20:07 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, опытный разработчик БД не станет утверждать это чуть более сложный рекурсивный CTE , не зная схем таблиц сущностей, в каком виде организованы ссылки на записи каталога. Если бы можно было использовать "чуть более сложный рекурсивный CTE", я не создавал бы здесь темы, опыта в PostgreSQL у меня достаточно. Суть темы совершенно другая. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 21:43 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Big Cheese Попробуйте ещё поспрашивать в соседней ветке: Проектирование БД Возможно дело не в хранилище, а модели данных. PS: а ещё бывают многомерные, мультимодельные СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 22:04 |
|
Graph DB vs RDF-storage
|
|||
---|---|---|---|
#18+
Big Cheeseопытный разработчик БД не станет утверждать это чуть более сложный рекурсивный CTE, не зная схем таблиц сущностей, в каком виде организованы ссылки на записи каталога. Наоборот, опытный разработчик предположит, что ссылки организованы одним из стандартных способов, оптимальным для задачи. Откуда и вытекает возможность достать данные простым и быстрым запросом. Если у Вас не получается написать простой и быстрый запрос, значит ссылки организованы неправильно. Только и всего. А отсюда следует, что Вам таки следует использовать СУБД с которой Вы знакомы и для которой способны сделать оптимальную структуру ссылок, которая и приведёт к простым и быстрым запросам. ЧиТД. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2020, 23:07 |
|
|
start [/forum/search_topic.php?author=%D0%B4%D0%B4%D0%B4&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 9499ms |
total: | 9681ms |
0 / 0 |