Standard lessons are the most common lesson type in GraphAcademy. They are text-based and can include code examples, images, videos, and questions.
Configuration
Example from neo4j-fundamentals course:
= Thinking in Graphs
:type: video
:order: 2
:image-path: images
You have learned that Graph databases store data in a structure of nodes and relationships.
In this lesson, you will learn why a graph database can be the right solution.
[.video]
// https://youtu.be/1g8hmyFO8xo
video::1g8hmyFO8xo[youtube,width=560,height=315]
[.transcript]
== Why Graph Databases?
Relationships in a graph are treated with the same importance as nodes that connect them.
This is not the same as other database technologies, as a result you may have experienced issues such as:
* Poorly performing queries when traversing complex schema of foreign keys and many-to-many relationships.
* Dealing with hierarchical data or trees, where the answer may lie at an unknown or varying depth.
* Finding a path through an ever-changing dataset with complex requirements.
* Simply finding it difficult to express what you are looking for.
These issues are often as a result of storing data in tables when the requirement is to understand *relationships* not *rows*.
=== The O(n) problem
Storing data in rows and columns is one of the oldest storage mechanisms and existed long before the computer.
Tabular data is a tried-and-tested methodology that works well for many use cases and an ecosystem of tooling exists to help you work efficiently.
However, as the amount of data grows or the application or use case becomes more complex, you may encounter challenges dealing with relationships.
When querying across tables, the joins are computed at read-time, using an index to find the corresponding rows in the target table.
The more data added to the database, the larger the index grows, the slower the response time.
image::images/growing-index.gif[An animation showing a growing index.]
This problem is known as the “Big O” or O(n) notation.
=== NoSQL Databases
Over the years, many No-SQL databases have sprung up to handle different scenarios, for example:
* Document stores offer flexibility.
* Wide-column stores offer scalability for large datasets.
* Key-value stores provide simplicity and high performance.
* Graph databases enable efficient modeling and querying of complex relationships.
image::images/no-sql-dbs.png[An image showing different types of NoSQL databases.]
=== Graphs
When you create a relationship between two nodes, the database stores a pointer to the relationship with each node. When reading data, the database will follow pointers in memory rather than relying on an underlying index.
This means that the query time remains constant to the size of the relationships expanded regardless of the overall size of the data.
A graph database yields much faster results for queries across entities and is a great fit when you need to:
* Understand the relationships between entities - how two people are connected
* Self referenced data of the same type - a hierarchy of employees within a company
* Explore relationships of varying or unknown depth - the use of parts within a factory
* Calculate a route between two points in a network - finding the most efficient route on public transport
Graph databases are a great fit for scenarios when you need to handle relationships efficiently.
[.quiz]
== Check your understanding
:leveloffset: +1
[.question]
= The O(n) notation problem
Related to relational databases - what is the O(n) problem?
* [ ] The challenge of maintaining data integrity during database updates.
* [x] Increasing response times as database indexes grow larger due to more data.
* [ ] Difficulty in implementing security protocols in relational databases.
* [ ] The need to frequently back up data to prevent loss.
[TIP,role=hint]
.Hint
====
When querying across tables in a relational database, the joins are computed at read-time, using an underlying index to find the corresponding rows in the target table.
====
[TIP,role=solution]
.Solution
====
The answer is "Increasing response times as database indexes grow larger due to more data".
Graph databases negate this issue by as the database stores a pointer to the relationship with each node. So when the time comes to read the data, the database will follow pointers in memory rather than relying on an underlying index.
====
:leveloffset!:
[.summary]
== Summary
In this lesson, you explored when graph databases are a good solution.
In the next lesson, you will learn explore typical use cases of a graph database.Required Attributes
-
:type: lesson - Identifies this as a standard lesson
-
:order: - Numeric order within the module (e.g., 1, 2, 3)
-
Title - Level 1 heading (=) at the top of the file
Optional Attributes
-
:optional: true - Makes the lesson optional for course completion
-
:disable-cache: true - Prevents caching of dynamic content
-
:lab: - Links to an external lab or sandbox environment
Completion
Standard lessons require a read:: directive to mark completion:
read::Complete the lesson[]The text inside the brackets is displayed on the completion button.
Auto-completion:
Lessons without questions are automatically marked as completed when the page loads. This approach maintains flow and removes barriers to progression, but doesn’t explicitly test understanding.
When to use auto-completion:
-
Introductory or overview content
-
Reference material
-
Context-setting lessons
-
When testing would interrupt the learning flow
Including Questions
Standard lessons can include questions using the questions:: directive:
questions::[]This will display questions defined in the lesson’s questions subdirectory.
Summary
In this lesson, you learned about standard lessons, the most common lesson type in GraphAcademy.
Standard lessons require :type: lesson, an :order:, a title, a read:: directive, and a [.summary] section.