The paradox of RELATIONSHIP: NoSQL vs. RDBMS

The paradox of RELATIONSHIP: NoSQL vs. RDBMS

The real paradox of RELATIONSHIP existence in current databases is that, in my opinion, a NoSQL graph database is MORE RELATIONAL than RDBMS can be. And this is an advantage of NoSQL, because its RELATIONSHIPS are richer and complete.
Why?
An example: a “friend” RELATIONSHIP in NoSQL graph database can include a “friends since” datetime stamp (a whole lifecycle of relationship), together with information in properties describing the degree and quality of this friendship (measure!!!), and so on. So we can automatically understand these rich relationships in runtime  :-)
As I have read this in my favorite book "Graph Databases" (authors: Ian Robinson, Jim Webber and Emil Eifrem) richer RELATIONSHIP is only one of many advantages of using NoSQL graph databases.
The very beginning of graph theory started in the 18th century by Leonhard Euler, who is a daddy and first pioneer of it. The graph theory is the study of graphs, which are mathematical structures used to model pairwise relations between objects. A graph may be undirected or directed, and it is just a collection of vertexes and lines called edges that connect them or in simpler way: a set of nodes and the RELATIONSHIPS that connect them.

The whole world for RELATIONSHIPS in a single graph…

Unlike RDBMSs, which require a level of specialized training to understand, graph databases store information in ways that much more closely resemble the ways humans think about data. In this context, we can easier understand the architecture of different networks (electronic and social), circuits, management and rules. And that is why graph databases have been proven to solve some of the more relevant current data management challenges, including important problems in the areas of social networking, master data management, geospatial, recommendations engines, and more. This increased focus on graph is driven by successes of companies such as Facebook, Google, and Twitter. So where we can use it? From the supply-chain to medical history for populations, and from the construction of a space shuttle, to a system of roads, and so on.
Major matter of the unique things about graph databases that makes them especially adapted to
modeling the real world is that they elevate RELATIONSHIP to be first-class principal citizens of the
data model.

Is there a great hope for economic world in graphs?

We live in a spacetime of the continuous threat of the “supersonic” domino effect, when the biggest worldwide bank can fall tomorrow without a special causes. Graph databases address one of the great macroscopic current business trends: leveraging complex and dynamic relationships to generate insight and competitive advantage.
For us it is hard to understand dynamic and “supersonic” relationships between worldwide supply and demand chain, customer’s needs, networks of power and energy, access elements in a
telephone or datacenter network, producers and consumers of entertainment, or genes
and proteins, gaming and military. Such RELATIONSHIPS are like protein neural networks in our brains which can starts with a one idea and occur real for ages. Maybe graph databases is the best tool to use theories of John Nash, an American mathematician whose works are used in market economics, computing, evolutionary biology, artificial intelligence, accounting, politics and military theory. The ability to understand and analyze such data in graphs is a key factor over the coming decade.

BASE vs. ACID

As I have read this in "Graph Databases", instead of using ACID (Atomic, Consistent, Isolated,Durable), the term BASE has arisen as a popular way of describing the properties of a more optimistic storage strategy:
1. (BA) Basic Availability:
The store appears to work most of the time.
2. (S) Soft-state:
Stores do not have to be write-consistent, nor do different replicas have to
be mutually consistent all the time.
3. (E) Eventual consistency:
Stores exhibit consistency at some later point (e.g. lazily at
read time).

Now I use Neo4j for the beginning from Neo Technology. MongoDB will be the next station soon  :-)