

Graphs: A Better Database Abstraction - arjunb
http://whydoeseverythingsuck.com/2008/03/graphs-better-database-abstraction.html

======
cchooper
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.

