7 ms·

"OrientDB does away with the concept of a join table, one of the most significant bottle necks in relational databases." I'm having a hard time not reading thi

"OrientDB does away with the concept of a join table, one of the most significant bottle necks in relational databases." I'm having a hard time not reading this as "joins are too hard for me to understand, so I love the idea of a no-join database"

Tloewald 13y ago
Agreed. It seems at best that they're simply reformalizing RDBMSs in a different way, and at worst they're losing something (depending on how inheritance and linkSets work). Not all joins are analogous to single inheritance, and multiple inheritance is intrinsically complex in pretty much the same way JOINs can be, so where's the win?
- catnaroek 13y ago
  I must disagree. Conceptually, JOINs are pretty simple. In fact, so simple that it admits a straightforward mathematical description.
  - lvca 13y ago
    To understand the difference between JOINS and direct links in a Graph Database look at: http://www.slideshare.net/lvca/why-relationships-are-cool-but-join-sucks-28997951 http://www.slideshare.net/lvca/why-relationships-are-cool-bu...
    - cwyers 13y ago
      Slide 18 is titled "The JOIN is the evil!" I will probably stop laughing at that, but I can't guarantee when.
    - catnaroek 13y ago
      A sales presentation is not going to convince me. I am interested in static guarantees of data integrity. I do not want to be worried whether I am inserting the wrong kind of data to a database, or whether by deleting some data, I am putting the database into an inconsistent state. For this particular need, I have found nothing better than relational databases in practice. There is still room for improvement, e.g. http://math.mit.edu/~dspivak/informatics/talks/CTDBIntroductoryTalk http://math.mit.edu/~dspivak/informatics/talks/CTDBIntroduct... , but that category-theory-based model is a refactoring and extension of the relational model, not a rejection of it.
    - mtdewcmu 13y ago
      I don't get the supposed benefits of direct links over joins. Index lookups are O(log n) or close to O(1) for B-tree and hash indexes, respectively. You can model any kind of graph in a relational database.
      - lvca 13y ago
        O(log n) is ok with small data, let's say up to thousands. But when you've millions or billions of record also the O(log n) takes time. It's about size. Until yesterday we managed small database in comparison to the today's BigData-Base. That's why a Graph Database makes sense today, much more than yesterday.
  - Tloewald 13y ago
    You're not disagreeing with anything I wrote. I said multiple inheritance is intrinsically complex in ways JOINs can be. JOINs can be used to do all kinds of wild and whacky things, they can also (easily) lead to horribly slow queries. They may be conceptually simple, but so is Universal Algebra.
    - catnaroek 13y ago
      We are disagreeing. Multiple inheritance does not admit an elegant (per Dijkstra: simple yet effective) mathematical description. Since it is a programming construct, however, there must be some description of it, which we also know must be ugly - we have ruled out it being elegant. JOINs are not intrinsically complex in the way multiple inheritance is. And they need not have bad performance either: it is just that relational databases have not caught up yet with the advances in category and type theory, and suffer from that accordingly. Saying schema-backed databases are intrinsically bad because SQL databases suck is just like saying static typing is bad because it sucks in Java and C++. And, yes, Universal Algebra is one big source of inspiration of mine, precisely because it leads to simple descriptions of large classes of structures.
      - Tloewald 13y ago
        Ok, i'm arguing that trading conceptually more complex multiple inheritance for conceptually simple JOINs isn't a win because multiple inheritance won't protect you from stuff blowing up. You"re just against multiple inheritance because it's a conceptual mess (I agree) without allowing for the argument that it might work better in practice (which I have anticipated and dismissed). Monopoly is concpetually more complex and less cleanly defined than Go, but not easier to play. I am saying that multiple inheritance is not Monopoly, but Go with extra, badly written rules. This is a pretty minor disagreement. You ignore a possibility, I mention it in passing and dismiss it. (Perhaps you're hung up on my stating that JOINs can be complex — conceptually complex is not the same as complex, just as universal algebra might breezily describe a realm of mathematics that has devoured the attention of geniuses for centuries.)
jhh 13y ago
what's a "join table" even? This speaks to a lack of understanding of how relational databases should best be used.
- chromaton 13y ago
  I believe they're referring to tables that have just two columns, both of which are foreign keys to other tables. They're used to create many-to-many relationships.
  - Pfiffer 13y ago
    I usually call them staple tables.
- asdasf 13y ago
  No it doesn't. It is a common term for tables that are just foreign keys to other tables, generally for expressing many to many relationships.
  - jhh 13y ago
    ok - that does indeed make some sense.
jetblackio 13y ago
I'm not so sure that it has anything to do with complexity of understanding. Joins make scaling RDMSs horizontally much more difficult, if not impossible in certain situations.
gayclimber 13y ago
I also notice that the only performance comparison against a relational database is where it says "A single server does the work of about 125 servers running MySQL". I was under the impression that MySQL is especially bad at joins, so I'd be more convinced by benchmarks involving Postgres or SQL Server.

Tloewald 13y ago

Agreed. It seems at best that they're simply reformalizing RDBMSs in a different way, and at worst they're losing something (depending on how inheritance and linkSets work). Not all joins are analogous to single inheritance, and multiple inheritance is intrinsically complex in pretty much the same way JOINs can be, so where's the win?

catnaroek 13y ago
I must disagree. Conceptually, JOINs are pretty simple. In fact, so simple that it admits a straightforward mathematical description.
- lvca 13y ago
  To understand the difference between JOINS and direct links in a Graph Database look at: http://www.slideshare.net/lvca/why-relationships-are-cool-but-join-sucks-28997951 http://www.slideshare.net/lvca/why-relationships-are-cool-bu...
  - cwyers 13y ago
    Slide 18 is titled "The JOIN is the evil!" I will probably stop laughing at that, but I can't guarantee when.
  - catnaroek 13y ago
    A sales presentation is not going to convince me. I am interested in static guarantees of data integrity. I do not want to be worried whether I am inserting the wrong kind of data to a database, or whether by deleting some data, I am putting the database into an inconsistent state. For this particular need, I have found nothing better than relational databases in practice. There is still room for improvement, e.g. http://math.mit.edu/~dspivak/informatics/talks/CTDBIntroductoryTalk http://math.mit.edu/~dspivak/informatics/talks/CTDBIntroduct... , but that category-theory-based model is a refactoring and extension of the relational model, not a rejection of it.
  - mtdewcmu 13y ago
    I don't get the supposed benefits of direct links over joins. Index lookups are O(log n) or close to O(1) for B-tree and hash indexes, respectively. You can model any kind of graph in a relational database.
    - lvca 13y ago
      O(log n) is ok with small data, let's say up to thousands. But when you've millions or billions of record also the O(log n) takes time. It's about size. Until yesterday we managed small database in comparison to the today's BigData-Base. That's why a Graph Database makes sense today, much more than yesterday.
- Tloewald 13y ago
  You're not disagreeing with anything I wrote. I said multiple inheritance is intrinsically complex in ways JOINs can be. JOINs can be used to do all kinds of wild and whacky things, they can also (easily) lead to horribly slow queries. They may be conceptually simple, but so is Universal Algebra.
  - catnaroek 13y ago
    We are disagreeing. Multiple inheritance does not admit an elegant (per Dijkstra: simple yet effective) mathematical description. Since it is a programming construct, however, there must be some description of it, which we also know must be ugly - we have ruled out it being elegant. JOINs are not intrinsically complex in the way multiple inheritance is. And they need not have bad performance either: it is just that relational databases have not caught up yet with the advances in category and type theory, and suffer from that accordingly. Saying schema-backed databases are intrinsically bad because SQL databases suck is just like saying static typing is bad because it sucks in Java and C++. And, yes, Universal Algebra is one big source of inspiration of mine, precisely because it leads to simple descriptions of large classes of structures.
    - Tloewald 13y ago
      Ok, i'm arguing that trading conceptually more complex multiple inheritance for conceptually simple JOINs isn't a win because multiple inheritance won't protect you from stuff blowing up. You"re just against multiple inheritance because it's a conceptual mess (I agree) without allowing for the argument that it might work better in practice (which I have anticipated and dismissed). Monopoly is concpetually more complex and less cleanly defined than Go, but not easier to play. I am saying that multiple inheritance is not Monopoly, but Go with extra, badly written rules. This is a pretty minor disagreement. You ignore a possibility, I mention it in passing and dismiss it. (Perhaps you're hung up on my stating that JOINs can be complex — conceptually complex is not the same as complex, just as universal algebra might breezily describe a realm of mathematics that has devoured the attention of geniuses for centuries.)

jhh 13y ago

what's a "join table" even? This speaks to a lack of understanding of how relational databases should best be used.

chromaton 13y ago
I believe they're referring to tables that have just two columns, both of which are foreign keys to other tables. They're used to create many-to-many relationships.
- Pfiffer 13y ago
  I usually call them staple tables.
asdasf 13y ago
No it doesn't. It is a common term for tables that are just foreign keys to other tables, generally for expressing many to many relationships.
- jhh 13y ago
  ok - that does indeed make some sense.

jetblackio 13y ago

I'm not so sure that it has anything to do with complexity of understanding. Joins make scaling RDMSs horizontally much more difficult, if not impossible in certain situations.

gayclimber 13y ago

I also notice that the only performance comparison against a relational database is where it says "A single server does the work of about 125 servers running MySQL". I was under the impression that MySQL is especially bad at joins, so I'd be more convinced by benchmarks involving Postgres or SQL Server.