The results of the great DB debate on The Register were announced. Although it was a close-run race, and RDBMS was well ahead at several points during the week before a late surge for graph DBs yesterday. Over 2,000 readers voted. This debate is a part of the current spotlight on databases.
Our first contributor, arguing FOR the motion, was Andy Pavlo, associate professor of databaseology at Carnegie Mellon University. Pavlo's starting point on Monday was that graph DBMSs are "fundamentally flawed and, for most applications, inferior to relational DBMSs."
Jim Webber, Neo4j's chief scientist and a professor of computer science at Newcastle University, arguing AGAINST, said in his rebuttal that he could not back the idea that "relational can do anything" and rejected the assertion that graph databases cannot properly support views and migrations.
Then, on Wednesday, Pavlo threw down the gauntlet, stating that abandoning the relational database model would be akin to "reinventing the wheel." He also doubled down on a public wager he'd previously made that graph databases won't overtake relational databases in 2030 by marketshare. He has promised that if he loses, Pavlo will replace his official CMU photo with one of him wearing a shirt that says "Graph Databases Are #1."
Webber then countered this in his Thursday argument, noting that the pending standard for graphs, GQL, is overseen by the same ISO committee that delivered SQL. If SQL extensions were enough to solve the graph problem, the committee wouldn't have bothered itself, he seemed to be saying. Instead, it decided graphs were different enough to warrant a full query language.
Webber also mentioned: In late 2010, I visited former colleagues at the University of Sydney, Australia. I gave a talk on graph databases and ended it by lightheartedly saying something like, "This technology category is going to catch on. You're going to ignore it for now, but in about a decade you will become interested and start telling us that we've done it all wrong."
Several papers from CIDR 2023 were cited in the discussion.
(Score: 2, Interesting) by Anonymous Coward on Sunday March 12, @02:42AM (2 children)
Not really my area, but this just sounds like the whole NoSQL vs. SQL debate all over again. NoSQL is great if you know your DB only needs to be queried in certain ways. If you want more flexibility you trade performance. I saw this on the job--we went NoSQL because we only had to do certain things with slews of data that were coming in and then being archived. I think they even tested it and our custom DB was 10X faster which made a noticeable difference on the front-end; but for more advanced queries where people were willing to wait for results we might have had a SQL for the archive. It's been a long time though, dead product anyway but the point stands.
(Score: 5, Insightful) by Thexalon on Sunday March 12, @04:04AM (1 child)
The basic story is that there's no such thing as a perfect data storage system for all applications, and you need to be smart about what you use for what purpose. How much stuff do you have? How quickly do changes need to be recognized (e.g. immediate, 5 minutes from now, sometime in the next 24 hours)? What percentage of your traffic is going to be reads versus writes (e.g. logs versus web content)? What predictions can you make about the structure of your data, and what changes are likely?
If somebody's going around touting anything as the perfect fit for every single possible circumstance, I'm going to assume they're selling that thing or being paid by somebody else who is.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by DannyB on Monday March 13, @03:44PM
That same "one solution for everything" mentality also is used for programming languages. If there were one language perfect for all uses, then we would all be using it already.
High level languages abstracted far away from the underlying hardware have a place. And low level languages that are close to the metal also have a place. Both have stood the test of time. They must be doing something right.
With languages as with databases. Use the right tool for the right job.
You can pound a nail into wood using an adjustable wrench. Yes, really.
How often should I have my memory checked? I used to know but...
(Score: 3, Informative) by Mojibake Tengu on Sunday March 12, @02:52AM (3 children)
Hypergraph database.
https://en.wikipedia.org/wiki/Hypergraph#Generalizations_of_concepts_from_graphs [wikipedia.org]
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 3, Interesting) by JoeMerchant on Sunday March 12, @04:36AM
SQLite has been all I ever needed. It just depends on your applications.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 1) by shrewdsheep on Sunday March 12, @10:46AM
I'm curious to know what is would add. As far as I can see, hypergraphs would offer new ways of representing relations, but not genuinely new concepts.
(Score: 2, Interesting) by khallow on Sunday March 12, @05:09PM
What sort of queries are you thinking of optimizing that you need this explicit hypergraph structure?
For example, some combinatorial markets have such a hypergraph structure. You have the atomic securities, then you have derivative securities, which can be based on multiple unordered securities. In particular, I'm thinking of so-called "idea markets" where the atomic unit is a yes/no claim (a binary pair of YES and NO securities with fixed total value and well defined exit conditions, and frequently intermediate payouts), but traders could trade boolean expressions of the claims (which would be where the hypergraph structure comes in).
(Score: 3, Informative) by RamiK on Sunday March 12, @12:31PM
GQL doesn't just support graphs. It supports tables, graphs and scalars along with complex pattern matching in a modern top-down language that eliminates most of the vendor-specific details SQL is plagued with. So, while it's fair to argue (as the author did when pointing out a paper that did just that early 2023) that existing rational databases can be easily (on a low budget) complemented with SQL/PGQ along with a few additions to support graph data structures, the same can be said in reverse: Once the likes of Oracle and PostgreSQL incorporate those graph features, there won't be a major downside to exposing a new GQL language front-end.
Anyhow, the GPML in SQL/PGQ and GQL is looking like a huge improvement over xpath and kin so I'm hopeful someone will put together xml/json parsing libraries around it: https://victor.marsault.xyz/resources/articles/GPMLSigmod.pdf [marsault.xyz]
That alone will make the whole thing worth while to me.
compiling...
(Score: 1) by khallow on Tuesday March 14, @01:41AM
That seems a particularly thin argument. An ISO committee assumes something is important enough to dally on, it somehow becomes important? I guess I'm not as impressed about ISO committees and what they deem important.