Hacker News Reader

Comment by lectrick | Hacker News Reader

"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"

View on HN

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.

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?

I must disagree. Conceptually, JOINs are pretty simple. In fact, so simple that it admits a straightforward mathematical description.

To understand the difference between JOINS and direct links in a Graph Database look at: http://www.slideshare.net/lvca/why-relationships-are-cool-bu...

Slide 18 is titled "The JOIN is the evil!"

I will probably stop laughing at that, but I can't guarantee when.

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/CTDBIntroduct... , but that category-theory-based model is a refactoring and extension of the relational model, not a rejection of it.

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.

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.

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.

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.

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.)

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.

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

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.

I usually call them staple tables.

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.

ok - that does indeed make some sense.

Reply on news.ycombinator.com