@Rolf: Ah, OK. Yes, the ACID issue is one point that I've seen come up before (and specifically for banking/finance). OrientDB (unlike many other graph databases) is ACID, so if that's the reason for the argument against graph databases, maybe it doesn't apply here? And of course, RDMBS' like Oracle and SQL Server certainly have an advantage in that they have been around longer, are more field-tested, and have potentially fewer bugs (although not bug free). That's a reasonable argument, but assuming that both technologies can be considered "reliable enough to not loose/corrupt data", my question is more about pros/cons at the architecture level (i.e. something that a graph database, and OrientDB specifically, is poorly suited for). That's what I'm curious about.
On Fri, Jul 31, 2015 at 11:46 AM, Rolf Streefkerk <[email protected]> wrote: > It probably comes down to proven technology and reliability. I don't have > any statistics, but I can imagine certain use cases where these factors > (basically ACID) are key. In the world of banking or space for instance. > Sorry, I don't have specifics either, but a look in this direction seems > logical for me. > > On Fri, Jul 31, 2015 at 11:13 PM, Eric24 <[email protected]> wrote: > >> @Rolf: Yes, that's understood. :) What I'm looking for is specific >> use-cases where an RDBMS would be significantly preferred over a graph >> database. Almost to the point of "when would a graph database be a terrible >> choice?" As @neRok said, I'm having a hard time finding those "do not use!" >> use-cases (especially when it comes to OrientDB, being multi-modal). Of >> course there are lots of people that have been working with RDBMS for years >> (like myself) that say graphs aren't good for this-or-that, but so far, >> I've been able to easily come up with reasonable graph architectures for >> each of them, so I suspect many of those opinions are based on their >> comfort with RDBMS. >> --Eric >> >> On Friday, July 31, 2015 at 4:42:57 AM UTC-5, Rolf Streefkerk wrote: >>> >>> Common use cases can be; master data mangement graph mapped solutions >>> like Facebook (relationships), Twitter. Another use case can be logistics. >>> Basically from my limited understanding, if you have a data-model that >>> contains many relationships (1-N, N-N) graph databases are very efficient >>> because of the directly linking to entities. There's no requirement for >>> mapping tables to slow this down like in SQL. >>> >>> >>> On Friday, 31 July 2015 06:45:05 UTC+7, Eric24 wrote: >>>> >>>> I'm learning more and more about OrientDB and graph databases every >>>> day. One question that I've seen lots of conflicting comments about across >>>> the Internet is use-cases where SQL/RDBMS are preferred over a graph >>>> database (most of what I've seen uses Neo4j as their graph database >>>> "foil"). I'm an expert-level SQL developer (with 20+ years experience >>>> designing RDBMS databases, in the past 15 years or so primarily using MS >>>> SQL), so I have a very firm grasp of what is possible there and what >>>> limitations exist, but I'm only getting started on graph databases (and >>>> specifically OrientDB, which so far, I'm very impressed and intrigued by). >>>> So I'd love to hear some feedback from some experienced OrientDB users (and >>>> authors) on use-cases that you would recommend be done using RDBMS instead >>>> of graph (and specifically OrientDB), and why. >>>> --Eric >>>> >>>> > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
