Comments on: Graphs vs. SQL. Interview with Michael Blaha http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/ Trends and Information on Big Data, New Data Management Technologies, Data Science and Innovation. Mon, 03 Nov 2014 17:39:20 +0000 hourly 1 http://wordpress.org/?v=4.2.4 By: John Goodwin http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-191 Wed, 04 Sep 2013 18:11:32 +0000 http://www.odbms.org/blog/?p=2047#comment-191 Michael,

If you have yet investigated triplestores I would strongly recommend you do. They are essentially graph databases. You mention:

Michael Blaha: Here are some advantages of SQL:

– SQL has a widely-accepted standard.

IMHO one advantage of triplestores over other graph stores if they use RDF and SPARQL – both widely accepted (open) standards from the W3C. There are many triplestores to use from so you have no vendor lock in.

John

]]>
By: Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-190 Wed, 17 Apr 2013 21:47:18 +0000 http://www.odbms.org/blog/?p=2047#comment-190 I don’t see the picture in my previous message after “When I see picture like this”. I use “img” tag to insert it/ I try to do it once again and give a link. It’s just an usual graph.
.

http://3.bp.blogspot.com/-4KrzYirz0VM/UEIqeaDuuRI/AAAAAAAAAAA/0QtrMs4PT70/s400/socnet-start.png..

]]>
By: Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-189 Wed, 17 Apr 2013 21:40:20 +0000 http://www.odbms.org/blog/?p=2047#comment-189 I would explain two my points.

Point one (an graph vs. schema).
Let me explain why I think that there is no opposition between graphs and schemas. When I see picture like this I understand that only two tables are enough in relational DB to present this graph even it will be million times more.

We have a constant simple schema of data which describe complex graph (because of the simplicity the schema may be not defined manifestly but it exists anyway). The graph describes an object domain, the schema describe data of this object domain. These descriptions are differ, but not opposite. They are orthogonal. For me there is no sense to compare them directly or in form of systems, which implement them.

Point two (“Why everybody wants and doesn’t want to replace RDBMS”).

For me current relational DBMS has only one drawback. Offering advantages of RM, they force users to describe object domain in terms of relational data model. “If you want to use relations you have to create the relations manifestly”. For me RM itself is very formal, and according to RM, all advantages of this formality are available when all data are presented as a set of relations. Once again: all data have to be _presented_ as a set of relations (not described manifestly! So RM doesn’t pretend ever to be used to describe something (inc. object domains).

Better ways exist to describe objects domains. But it doesn’t mean that it’s necessary to throw out relational DBMS, because RM really has a big number of advantages. Unfortunately specialists who understand that RM is not good to describe object model (once again RM doesn’t pretend to do it) try to forget about RM in a new DBMS at all. As a result tons of the new DBMS appear which offer to user a kind of revolution both for mentality and to practical work

But all, what a most of RDBMS users need, is just an ability to describe object domain in more natural way and, then, present the object domain data in relational form.

]]>
By: Reinhold Thurner, http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-188 Wed, 17 Apr 2013 13:28:32 +0000 http://www.odbms.org/blog/?p=2047#comment-188 I would like to discuss the pros and cons of different approaches for “storage system” in relation to a basic reference model. Such an approach has been proposed by Peter Chen in his famous paper “The Entity-Relationship Model – Toward a Unified View of Data”. His ideas provide us with the means to express the differences between DMBSs or their shortcomings in comparison to the generic model. The profile of a “storage system” can be described by (1) the existence / model of the schema, (2) the model of the instance level and (3) the functionality of the system (as e.g. ACID-support, access-language, performance). Depending on the purpose and circumstances a data store may live well without a schema and can operate without ACID or formal access-language – if it is prepared to pay the price for such a profile.
A graph data base has (1) no schema – or at least not a formally defined schema. There is a sort of implicit use of a “schema” in each query – otherwise it would be impossible to define a generic search: You specify a search “Friends” that “work_together” – and not “amici” “lavorando insieme” – because you know that there are entity-types releated by relationship-types with exactly these names. On the instance level (2) graph data bases know about entities with attributes and about relationships but without attributes. They provide(3) the D(urability) of the ACID-package and a toolbox to access the instance data, but no formal, schema-related language.
A relational DBMS has a (1) schema with entities and process-related relationships (constraints). The constraints can be derived from the conceptual model, but are not a complete representation of the conceptual (entity-relationship) model. On the instance-level (2) an RDBMS knows about entities (tables) and attributes (columns) but there is no equivalent to a relationship. The relationships of the conceptual model are emulated on the instance level by foreign keys or relation-tables for m:n relationships or relationships with attributes. The SQL-query-language (3) reflects the tabular schema and reestablishes relations via the interpretation of special attributes (foreign keys) in a join-operation. It is common practice to use the conceptual model only for the initial design and the creation of the first cut database; it is never really tested and not included in the evitable changes of a database. It finally “remains pinned to the wall” (Blakely) as an outdated document.
The integration of (1) the (entity-relationship) based schema and (2) a congruent instance-model leads to an erDBMS. Such a DBMS stores the relationships between entity-instances and the attributes of relationships in the database. This has an impact on performance – it slows down the write process and speeds up the read access. (3) An erDBMS provides full ACID-support and has an access-language (erSQL) related to the conceptual schema. It navigates (similar to a graph database) through the structure and collects attributes controlled by an SQL-like select-statement. Schemas are extensible; changes to the schema which affect the instance data require also changes to the instance data: the structural consistency of schema and instance data is automatically enforced. An erDBMS is certainly not another form of an ORM which attempts to bridge the semantic gap between the conceptual model and the (relational) instance data.
SQL-databases are undoubtedly the market leader – Stonebraker has sufficiently explained why this is the case. This may change with the combination of the erDBMS-model using in-memory storage. Our tests with Metasafe and VoltDB (as persistence layer) show promising results.

]]>
By: Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-187 Tue, 16 Apr 2013 20:53:17 +0000 http://www.odbms.org/blog/?p=2047#comment-187 Thank you for the interview. It’s very interesting for me. And it’s very usual.

First of all I cannot understand at all how it is possible to oppose the term “schema” to the term “graph”. Michael said that graphs are well-known since a time of network databases. But the network databases always have a scheme. If I have data schema described in OO terms and I will get a graph of objects linked with references. So there is no opposition between graphs and schemas.

Secondly. Michael said that “Relational databases permit navigation via joins”.. I would correct this phrase as “Today relational DBMS permit navigation via evident joins” because generally relational DBMS can permit navigation without evident joins but with very usual navigation paths. Relations do not oppose to the navigation, it’s just a drawback of existing RDBMS.

And I think it’s better to use term “DBMS” when we are speaking about data manipulation abilities because “database” is just big piece of data.

A good news for me that “possible performance differences (between relational DBMS and other ones – EG) are often not obvious”. It means when “difference in expressiveness” is the only problem. But (once again) this is not a general problem and this is not a SQL problem even (it’s just a language which can be slightly extended to get new possibilities). You can visit my site http://rxo-project.com to be convinced of this.

]]>
By: Roberto V. Zicari http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-186 Mon, 15 Apr 2013 19:51:26 +0000 http://www.odbms.org/blog/?p=2047#comment-186 How DEX relates to Graph databases? Please explain,

]]>
By: Pere Baleta http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/#comment-185 Mon, 15 Apr 2013 15:48:12 +0000 http://www.odbms.org/blog/?p=2047#comment-185 Very interesting view about Graph Databases. We, at Sparsity Technologies, are the developers of DEX (http://www.sparsity-technologies.com/dex)

Thanks
Pere

]]>