I, too, have very many years worth of experience with so-called relational databases. Starting with Informix in the 1980's. However, I never really considered them to be properly relational.
In the mid 1970s I used the Honeywell (formerly GE) IDS database. This was (at the time) considered to be a relational database. In fact, it was similar in many respects to today's graph databases. The problem with this type of database was that, at the time, designing and implementing a database was a complex task - and changes to the schema often required unloading and reloading the whole database. From the perspective of a programmer *accessing* the database it was rather nice - although the chains of subrecords were not as flexible as current edge links. When I was first introduced to a so-called relational database, my first reaction was "That's not a relational database, it's a collection of index-sequential files!" This is the root of the whole RDBMS problem. Yes, the query-language handling built in to the database manager simplifies data management and lookup, but in reality the whole thing is rather a kludge. The one real benefit of these is that they have coerced people to thinking about normalisation - an area where I find the majority of NoSQL solutions seriously deficient. I seriously cannot think of any database implementation over the past 30 years where I would think "Yes, given the choice, it would be much better to use PostgeSQL/Oracle/MySQL etc." rather than a graph database. OTOH, there will still be occasions where - due to existing infrastructure - it will continue to appropriate to use / extend an RDBMS. My current project was originally designed (by me) using postgreSQL. I needed many more link tables than actual data tables due to the range of relationships needed. The nice thing was that postgres has inheritance. The nicer thing is that so does orient :-) My design using orient is much cleaner - even though the potential relationships have grown On Friday, 31 July 2015 17:54:24 UTC+1, Eric24 wrote: > > @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] > <javascript:>> 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] <javascript:>> >> 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.
