Graphs: A Better Database Abstraction

Total nonsense. I'm no relational-junkie, but I know a bad argument when I see one.

Firstly, the author can't decide whether relations are an abstraction or not. At points he seems to be preferring graphs to relations because graphs are abstract and relations aren't ("the anti-abstraction argument rears its head in the RDBMS vs graph database debate"). At other points, he admits that relations are also abstractions, but argues that graphs are more suited to the data we actually use. Seeing as relations are just as abstract as graphs, we can ignore all the stuff about abstractions being a good idea. Yes, we know; that's why we use relations.

Secondly, despite this being a post about abstraction, he doesn't distinguish between a physical implementation and a logical representation. Yes, a SQL database can store graphs inefficiently, but that's a problem of how the relations are physically stored, not a problem with relations themselves. You can store a self-joining relation just like a graph, and optimise it for graph-like queries. That's the beauty of abstraction!

Thirdly, he claims that graphs are better when the structure of your system will change frequently. There's no argument for this, it's just a non sequitur he drops in at the end. It's true that most RDBMSs are very static in nature, but that's because they have been designed reap the rewards of static typing. They don't have the be that way, and I can't see that graphs give you any benefit here.

Fourtly, he claims that 'you want an abstraction that reflects how you really think about the data and not some jury-rigged representational model continuously intruding itself into your thought process.' True, but graphs are just as much a jury-rigged representational model as relations. Almost every system needs to store data about users, but users are not graphs (nor are they relations. Don't confuse your data model with reality!)

A database is something we build abstractions on top of. These could be graph abstractions, or object-oriented abstractions (ORMs) or whatever. A database does not dictate the abstractions you use, it simply provides an abstraction for data storage. Such an abstraction should be chosen because it can store all the different kinds of data you need, and provide constraints that prevent the data from becoming incoherent. These are the important considerations, and they aren't even mentioned.