Discuss the practical exercises for graph databases. Do you understand the queries and what they are doing?
In SQL, the creator of a database needs to define the schema up front: that is, what columns each table is going to have, and the datatype of each column. This means that all rows in the table have the same set of columns (although some of them may be set to NULL if the value is unknown).
On the other hand, Cypher does not have an explicit schema: a node can have any set of properties, and you can always add a property with a new name to an existing node.
Discuss the pros and cons of these two approaches.
In the graph databases tutorial we showed a Cypher query for find the number of co-actors for Jennifer Lawrence. How would you write the same query in SQL?
We discussed several examples of Cypher queries that have close equivalents in SQL, and some examples that are hard to express in SQL. Discuss: would it make sense to move existing SQL-based applications to Cypher? In what circumstances would you choose one query language over the other?
In the example graph database, there are 22 nodes of label Genre, but in the relational database, the genres table has 273 rows. How do you explain this discrepancy? What are the consequences of this difference in data model?
What do you think the database software is doing internally when you ask it to find the shortest path between two nodes? Describe it in words (no code required).