|
|
|
|
|
|
by inkyoto
1287 days ago
|
|
|
> You can do all of this in the relational model […] That… depends. Right now I am dealing with the customer's 6NF relational model which I had up until now thought was purely theoretical and was not a naturally occurring phenomena (my previous record was a 4NF some years back). ERD's for core data entities span several screens across and are, in fact, a thing of beauty, but… It is difficult to reason about the data that has historically grown over the last 20 years. The incoming data model is a document data model, therefore dependencies between data entities in such a highly normalised model need to be analysed first. A graph database turns out to be a good fit for the data relationship analysis in highly normalised relational data models as well since normalised entities effortlessly map onto graph nodes and relations onto graph edges. The document data model can be thrown into the mix on top of the relational model with new relationships being incrementally added, linking the relational and document data model entities together. Ad-hoc queries are also much simpler in the graph DB as less interesting relations can simply be ignored for a moment. In the end, graph nodes and/or edges can be enriched with extra useful properties giving one nearly complete data model migration mappings. There is nothing with the relational model, and it is an appropriate fit for many use cases. However, if one has never gone beyond joining 3 tables in a single query for a web app, or if one has never encountered a extremelly normalised data model, it is difficult to see where the relational model falls short. Relational are also rigid and do not accommodate changes easily whereas graph models allow for new relationships to be added incrementally as the data model evolves. Also not to mention that most relational models do not venture past the 2NF model, and the dataset is typically an entangled mess of organic or historical growth. |
|
|