I've been reading a book on graph databases that is fascinating to me. Having never worked on one or written a query involving one, I've wondered what the media hype I have seen across the last year or so is about. It is an intriguing idea, and I'm looking forward to playing around with one or more of the graph implementations. 

While I find the technology interesting, I wasn't exactly sure how well it fits in many of the problem domains I've solved with RDBMSs in the past. I'm still not sure many of the sales/inventory/accounting problems lend themselves to a graph system over a relational mode. I do, however, think many of the linked data in systems like Twitter, LinkedIn, Facebook, and more are better suited to a graph system, where the queries are along a specific set of links, and the volume might be prohibitive for the relational model.

This week I also found an article on modeling across data stores, using relational storage, JSON, graph, and key value formats. There's a good description of a problem, in this case, parts and maintenance for aircraft. The case study shows that certain queries are very well suited for graph databases, but others require "secondary indexes", which seem almost like a way of getting around the graph store. The analogy might be having some row-store indexes and some columnstore indexes to handle different queries. Certainly these are very feasible ideas, but with an increased resource requirement to maintain and store the extra index data.

The modeling doesn't include an RDBMS, but I suspect in the real world there would be a relational component for some of the data. My suspicion is that in the future, more and more of us will run into situations where we might want to consider modeling our data across different types of structures. Even if we are sure SQL Server can manage the load, I wouldn't be surprised to find that some developers implement JSON, graph, or other stores for applications, which will also query SQL Server. At the very least, I would think many data professionals would want to understand some other data stores just for the practical requirements of performing ETL.