TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Why not use Graph DBs as a general purpose DB?

5 点作者 rottyguy超过 9 年前
Am investigating some db technologies for an application I&#x27;m working on and just came across Graph DBs (note I&#x27;m not a db guy). Just playing around a bit with neo4j&#x27;s online REPL felt a little more natural to model out data. However, as I dig into it, people seem to take the stance of GDB being particularly well suited for certain applications but stick with Relational where possible. Is this mentality more about Relational being much more widely adopted in society today (and thus more tested, optimized, understood, etc.) as opposed to some deficiency in modelling problems with graphs (I&#x27;m inclined to make a comparison between functional language vs object oriented vs procedural programming languages where thinking in Graphs these days causes a bit of a mental shift and therefore dissuaded b&#x2F;c it &quot;feels&quot; different -- much like going from C (procedural) to C++ (oo) and now C++ (oo) to F# (functional) )<p>For example, if we just take a simple case: Modelling out a Restaurant Menu that serves Breakfast, Brunch (on Weekends), Lunch, Dinner, Desserts, Drinks, I can see both GDB and Relational being able to solve the problem but why would I necessarily choose Relational over GDB (or vice&#x2F;versa)?

1 comment

amirouche超过 9 年前
Because graphdb are not good at listing&#x2F;scanning single types e.g. Lunch, Dessert, Drinks, etc. Simple queries have similar complexity but there is no optimization for the mildly complex queries:<p>&gt; SELECT COUNT(drink.id) FROM lunch, drink WHERE lunch.id == drink.lunch_id ORDER BY lunch.delivery_date, lunch.total_price<p>Everything that is not recursive is better served by RDBMS.<p>My understanding is that it&#x27;s not that it&#x27;s impossible to optimize the RDBMS usecase in graphdb implementation but that it&#x27;s difficult in terms of query language to express both the traversal and scan. Arangodb want to be tackle that area through AQL.<p>You can also build somekind of graphdb schema, a specific graph topology that alleviate the need for specific optimization by basically denormalizing the schema.<p>&gt; I&#x27;m inclined to make a comparison between functional language vs object oriented vs procedural programming languages<p>IMO tinkerpop and neo4j looks like Python (dynamic oo and functional language) vs Java (static typed and class based) which look like RDBMS. ArangoDB and OrientDB (multi-model) looks like Scheme Guile.<p>Even if graphdbs have weakness, like dynamic programming, they allow to build things more quickly.<p>&gt; where thinking in Graphs these days causes a bit of a mental shift and therefore dissuaded b&#x2F;c it &quot;feels&quot; different<p>Yes definitely. That said from my point of view, it&#x27;s clear where a graphdb &quot;is the right tool for the job&quot; whereas functional programming is a writing style that can be applied to procedural or OO languages; It&#x27;s not clear what&#x27;s the pragramatic purpose of purely functional language.
评论 #10326516 未加载