The goal for this course was to introduce you to some common types of databases. We covered:

• SQL databases

• Key-value databases

• Document-oriented databases

• Graph databases

Let’s run through some of the key takeaways from this course for each database. Relational databases are a type of database which represents data in terms of tables, columns, and rows. Tables are used to model specific concepts. Columns describe an attribute of the concept being modeled. They include names, data types, and optional constraints. Rows are collections of columns representing a single instance of a concept. 

Concepts which cannot be modeled effectively using a single table can be broken down into multiple interconnected tables. Which is a common practice when following database normalization best practices. Relational databases are commonly programmed using the domain-specific language: SQL. 

SQL is used to create and control relational databases using a minimalist English-like syntax. The structure of a database is called a schema. SQL databases codify data integrity rules into the schema. Allowing the database to be responsible for its own data integrity. SQL databases have many use cases ranging from data exploration and visualization to application storage, and many others. 

A few common examples of SQL databases include: 

• Postgres

• MySQL

• MSSQL

• SQLite

 Key-value databases are collections of key-value pairs of data. They can set, get, and remove value data based on a key. They don’t typically include a query language. Rather they tend to provide either a client library or command line interface. Key-value databases are basically giant lookup tables. Which makes them useful to engineers for many different use cases. For example, data caching, centralized metadata lookup, embedded application storage, etc.

A few common examples of key-value databases include:

• memcached

• redis

• etcd

Document-oriented databases are databases whose fundamental unit of data is called a document. Documents consist of attributes which describe the concept being modeled. Documents exist inside of a collection. A collection is just a namespace for a group of related documents.

Documents inside of a collection aren’t required to use the same set of attributes. Document-oriented databases are considered to be schemaless because they don’t enforce any constraints when the data is saved to the database. This flexibility shifts the burden of data integrity from the database to the developer.

Many document-oriented database implementations represent documents using JSON or a similar format. Though query mechanisms vary across implementations. Document-oriented databases are commonly used for: iot, game development, catalogs, mobile applications, event logs, etc.

A few common examples of document-oriented databases include:

• MongoDB

• Elasticsearch

• DynamoDB

• CosmosDB

Graph databases are used to store and explore data and its relationships. Data is stored as nodes and edges. Nodes model concepts using properties and labels. Edges model relationships between nodes. Edges may or may not include a direction depending on the use case and database implementation.

Graph databases don’t have a standard query language. A few common language examples include:

• Cypher

• GraphQL

• AQL

• Gremlin

• …

Being able to model data and relationships has a wide range of use cases including fraud detection, recommendation engines, social networks, network topologies, and the list keeps going. A few common examples of document-oriented databases include:

• Neo4j

• DGraph

• ArangoDB

• …

Working with data is part art and part science. The science part comes in the form of the engineering efforts that go into data structures, efficient data retrieval, query languages, etc. The art of it comes in the form of a holistic understanding of your specific use case. The better you understand your use case, the better you’ll be able to model and consume your data. 

Hopefully, this course has given you a glimpse into the world of databases. There are many different types of databases; each with its own set of tradeoffs. And this course only scratches the surface of the capabilities of these databases. 

If you’re interested in learning more about any or all of these databases I recommend installing and exploring them for yourself. Hands-on learning will help you to more fully understand the capabilities of these systems. 

Okay, that's going to be all for this course. Thank you so much for watching. And I’ll see you in another course!