Posts by szilardbarany 5 publicly visible posts • joined 2 Nov 2017
It's not SPARQL that you need but a graph query language. An RDF triple store is not a property graph database. A knowledge graph is not a graph database. A real property database (be it a typed one, like TigerGraph, or a labelled one like Neo4J) can store and process large and complex networks of interconnected data. A supply chain is a good example, or a complex ETL/ELT process; in general any dependency related problems.
See my other comment for this article.
You are indeed a cranky old codger. And you haven't seen a proper graph databases and/or a proper graph use case.
I worked with/for some of the biggest RDBMS vendors, have modelled OLTP and DW databases, wrote plenty of SQL, but I also used proper graph database to tackle proper graph use cases where an RDBMS would not have a chance. Graph DBs have their place in the landscape. Currently it's a niche, but as more and more people/companies understand what they really can do, the market slice will grow too.
See my other comment here.
"Graph databases – in which relationships are stored natively alongside the data elements – do not provide a significant advantage over well-architected relational databases for most of the same use cases."
Why would you want to use a graph database for a use case that can be solved in a relational database? Solve problems instead that would be too expensive/too time consuming/impossible to do in an RDBMS. Try to figure out if this banking transaction is in connection with any known fraudsters within 10 hops. Try to find out who fas those small farmers in Ecuador, Nigeria and Papa New Guinea from whom the raw ingredients was purchased for a product that was complained about when the process between the final product and the raw ingredient includes a massive and complex network of processing, transporting and internal trading steps. (FYI: 12 sec in graph DB vs 15 hours/timed-out query in RDBMS.)
What the article states is: "Screwdrivers do not provide a significant advantage over a well polished hammer for most of the same use cases (e.g. dealing with nails)."
You have no idea what are you talking about. A modern graph database stores graph in it's native form: as vertices with their outgoing edges. Not in tables, not in docs, not in K/V stores. There are MPP graph databases, that can ingest data in real time and can ran complex analytics (including the several dozen graph algorithms, like shortest path or circular detection) in very fast response times. Multi-hop queries (several dozen hops over edges) are easily possible. Storing and processing billions of vertices and edges is possible.
Have you ever seen a graph database?
(Note: I am a Teradata/Think Big Analytics employee)
With due respect, I completely disagree. Teradata (technology in general, and RDBMS in particular) is not more complex than any of the competing technology. The roll-out problems at Unilever were probably an exception (will check the story with the sales guys); we had/have a huge number of successful implementations. We do not just sell stuff; we provide solutions and we rely (financially, i.e. my salary) on successful roll-outs to ensure that our customer get more eager to use more of our tech and services. We are #1 in our biz after all.
On the new announcements: the ability to Aster Analytics functions (and then TensorFlow, Spark and more) on TD is a great news, more stuff to do with your data without moving it around.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
