The Netflix sample database is a learning database based on public data from Netflix’s Engagement Report and Global Top 10 lists. This guide walks you through installing it on PostgreSQL.
For more background on this database, see my introduction to the Netflix Sample Database.
If you’re learning SQL or looking for a real-world dataset to sharpen your database skills, the Netflix sample database could be an option. This free, open-source database is based on publicly available information from Netflix’s Engagement Report and Global Top 10 weekly lists, making it both relevant and engaging for practice purposes.
Common Table Expressions (CTEs) are a handy way to break down a complex query into readable, reusable pieces. When you need several intermediate results – say, a filtered set, an aggregation, and a ranking – you can stack multiple CTE definitions together. PostgreSQL, SQL Server, MySQL 8+, and many other engines support this syntax.
Prepared statements are a precompiled SQL queries that we can execute multiple times with different arguments. They are limited to the current session, so we can only create them and run them from within the same session.
Sometimes we might want to review how many prepared statements we’ve created. Or we might need to deallocate one, but we’ve forgotten its name.
No problem. We can use the pg_prepared_statements view to see all of our prepared statements.
The SERIAL data type in PostgreSQL is a pseudo-type used to create an auto-incrementing sequence of integers for a column. It is commonly used for primary keys, as it eliminates the need to manually assign unique identifiers for each new record. PostgreSQL handles this by automatically creating a sequence object that supplies a unique number each time a new row is inserted.
PostgreSQL provides three SERIAL types, each with two options for usage; which effectively equates to six different types. So basically, we have six options to choose from when creating a SERIAL column.
When a foreign key is defined in a table, it ensures that the values in the column(s) correspond to values in a primary key or unique key in another table. While PostgreSQL automatically creates an index for primary keys (because these need to be fast for lookups and enforcing uniqueness), it does not automatically create an index for foreign keys.
There are several ways that we can list all indexes in PostgreSQL. These include utilizing various system catalog views and psql commands. Below are five options for returning a list of indexes in PostgreSQL, along with examples of how to filter the results by index name, table name, and other criteria.
If you’ve been working with prepared statements in PostgreSQL, you may get to a point where you no longer need one or more of them. In that case, you might want to remove them, or delete them, drop them, or however you want to say it.
Fortunately, this is one of the quickest, easiest things to do in PostgreSQL.
The \di command can be used to list indexes in the current database when using psql (PostgreSQL’s command-line tool). This meta-command can display all indexes, or just indexes that match certain patterns. Here’s an in-depth explanation of how \di works, its options, and examples of its various uses.
In PostgreSQL, domains are basically data types with optional constraints. We can create them as a kind of user-defined data type, and then reuse them in our columns going forward.
As with any user-created object, we sometimes need to see a list of existing domains in a PostgreSQL database. Listing all domains can be useful for database management, documentation, or troubleshooting.
This article will show you how to retrieve a list of all domains in your PostgreSQL database.